I have been looking around but haven't been able to find anything concrete on this so apologies if it has been asked before.
I am using Swagger codegen to create a ServerStub for my Lumen API project that I am making which is working just fine. My confusion comes from where am I meant to put in my server side logic for connecting to the database, etc.
All files in the middleware and controllers folders, as well as routers.php explicitly state Do not edit the class manually in the header comments of each class. So I'm a bit confused where I am supposed to put my logic after the creation of the Server Stub.
Can anybody shed light on where to I put my implementation of the project to use the Server Stub provided? Because the comments tells me not to edit the class, I feel like my implementation is meant to be abstracted away somewhere but I'm just not sure where.
Appreciate any help on the issue. Thanks.
Related
I wanted to try out the code first approach with an OpenAPI spec. For testign purposes I treied the Pet Store Example from SwaggerHub.
In the generated Code I noticed, that there is no logic involving routing.
I also noticed that the code in the service folder is not even used when I run the nodejs server (changing values of example data changes nothing in the output. The API seems to run a swaggerhub server.
Do I have a missunderstanding here, what the swagger code gen does?
On the other hand the client code generation looks how I woudl expect it. Instead of creating rest requests in my client I only have to execute methods of the services.
Based off your question, I would argue you're actually doing a "design-first" approach.
Code-first is when you have an existing codebase/service and you then create your documentation after (whether it is generated or hand written).
A design-first approach is when you create your documentation first, and THEN build out your code. If you have an OpenAPI document, and you're using Swagger codegen to create some code, then you're doing design-first.
As for your question involving routing, all Swagger codegen will do for you is generate some boilerplate code based off of your OpenAPI document. It will not add any business logic, or even route the API calls for you. It is then on you to implement all this logic after the fact.
I am currently defining a Rest API and I intend to use Swagger to document it.
I've already started to define my API specifications with the Open Api Specification in YAML into the Swagger-Editor.
Then, I understand that I will provide that file to the Swagger-codegen to generate a server implementation, and also to the Swagger-UI (whose statics files will be previously paste to my server) to expose the interactive documentation .
According to Swagger, this is the top-down approach.
But later, I will probably need to modify this API, and I want to do it via by this tediously YAML file previously defined, to keep the API easily modifiable by anyone (and Language-agnostic).
Does the way to do this is to modify the definition file and then re-use Swagger-codegen ? By this approach, I guess so that I can't even lightly modify the API directly in the implementation server code without risking to have a out of date documentation.
And If I chose to do the bottom-up approach (via Swagger-core annotation), I will restrain all my further modifications to occur in the implementation server code, and my initial definition file will never be usable again.
So another question would be : Is there a common way to deal with Swagger when we want to modify the API both via the specification file and via the implementation server code (I suppose that the file that Swagger-core can generate me from my code, will never looks like my initial one that I defined by hand).
To maintain the API documentation, the best course of action that i can suggest is to follow a hybrid approach.
Initially, when you have to do bulk development, go for the top down approach. This will reduce the initial set up and coding effort. That's the basic idea behind any codegen.
Then, when it comes to maintaining the APIs, or adding a few new ones every day (or week), follow the bottom up approach. You will already have the previous code, the only thing you'll need to do is add some more annotations or API definitions.
Going for top-down iteratively defeats the purpose of code maintenance. Boiler plates and self generated code are there to give you a quick start, not for sustenance.
My opinion may be biased.
For API client, there should not be a need to customize it in most cases. If you find that you need to customize it to meet your requirement, it may worth starting a discussion via https://github.com/swagger-api/swagger-codegen/issues/new (and also please check what are the options available to customize the output, e.g. for PHP, run java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar config-help -l php)
For server stub, ideally the developers only need to focus on the business/application logic and regenerate the server stub when adding/deleting/updating endpoints (but I don't think all the server stubs can achieve that yet)
Disclaimer: I'm the top contributor to Swagger Codegen
I am having trouble getting started on my first attempt with EF and Code First mostly due to trying to find an efficent way to organize the project in Visual Studio. I wanted to try Code First so I pictured a set of class files in a separate project to describe the entites, like MyApp.Models. To build on that I imagine I need something like Fluent API to make sure the database is created the way I expect which is where I hit the first snag. I think the only way to do this is to define the context where EF generates the database. So where should that code creating the context be defined? In a separate project like MyApp.DAL? I'd also like to include Asp.Net Identity 2.0 which I believe is part of defining the context so that is included in that step. Next I assume I need to actually call the code so EF can generate the DB which requires at least a configuration setting for the connection string. Eventually I want an MVC app but maybe next is a console EXE like MyApp.ConsoleTest? Also I'd also like a Web API project which would serve the MVC app. I think those can be covered with something like MyApp.WebAPI and MyApp.ClientWebMVC. Perhaps later I could also create MyApp.ClientWPF which would leverage the work done with the Web API. Along the way I should also probably have something like MyApp.Common or Shared.Common to hold things like logging and error catching.
I think the first few steps around the entities and context are what trip me up the most. I want to try and organize the data part of the code so changes can be isolated from ruining too much in the client apps. Is there a good tutorial on project organization that addresses EF Code First that isn't overly complicated (ie Unity of Work)?
I asked this question over on the asp.net forums, and nobody seems to know what i'm talking about. I'm not sure why that is, but I figured I'll ask here to see if there is anyone with some insight.
Back when MVC2 was released, it included a sample AccountController that wrapped the built-in Membership and FormsAuthentication classes with testable interfaces and services. I read a lot about this, and it was considered a good thing because the Membership and FormsAuthentication classes were not easily testable.
Recently, I generated a new sample project with my up to date (SP1, MVC3, Tools Update, etc..) environment and I find that the AccountController is now much simpler. Gone are the Interfaces and MembershipService and FormsAuthenticationServices. The sample now calls the Membership and FormsAuthentication classes directly.
I'm wondering if anyone knows when this happened and why? Are the testable interfaces no longer considered correct? Was there a technical reason to change this?
The best I can figure is that this happened as a part of the change to remove a possible vulnerability when passing return url's on the open url.
Any insight?
The new model resembles EF's code first approach where the AccountModel is a POCO class. Inside the new API there are no longer abstractions but direct calls to static methods such as FormsAuthentication.SetAuthCookie making this code difficult to unit test. Not something I would recommend basing your real world application code upon.
And, yes, they have fixed a vulnerability inside the LogOn method which was not verifying if the return url is a relative url before redirecting.
Personally I would recommend you using abstractions in order to weaken the coupling between your controller logic and its dependencies. This will make the code easier to unit test.
For me passing all those domain models to views without using view models are total anti-patterns and I have never bothered with them. I simply create an empty project and do the things my way. I mean in the default project they even use ViewBag for Christ sake!
The Account Controller was changed with the MVC3 tools update (When they also included the use of jQuery via Nuget)
Im really new to Grails and I try to understand how it works. I did some tutorials and wrote a sample application with a mysql database connection. Ive got three tables and therefor three domain-classes and three controller using def scaffold = true. So the views are generated automatically. Now I can add and remove and ... the data in my tables. Thats working.
But now I dont know how to go on. I mean, creating those tables and filling them is nice and its nice that this is possible so fast, but... Now I really want develope an application! Normally I work with Spring Framework, Spring Security, Spring MVC and so on to generate web applications. There, everything is logical. I have the requests comming in, the mapping to controllers, classes which work on the requests, answers given back, jsps rendered.... logical!
In Grails, I dont even know where to start for a real application! All tutorials I find show the same: Setting up those tables and being able to fill them, nice, nice - but after that?
Where do I save the "main.gsp". Do I need a controller for it? How does the application at start up redirect to "main.gsp".
Where can I define the "real logic" - I want to develope something like a "questions with multiple answers - try to select the correct answers"-application. Well, I must admit, I really dont know where to start. And I don't see the use of the Controllers and the possibility to add Data to my tables in my application. Thats for admins but not for users.
Could anyone give me an hint how to go on? Or maybe someone knows a good tutorial which is not about "setting up domain classes, controllers with scaffold, adding data to your database" - I dont see so much sense in it.
Thanks for your help! :-)
[EDIT] Thanks for the answers! Services, that was exactly what I was looking for. I guess I simply must get more familiar with it. The tutorials were just confusing me, but now I understand better!
If you are familiar with Spring and Spring MVC, the concepts in grails should be no surprise to you. Grails actually uses Spring MVC under the covers.
Grails can auto-generate Domain classes, controllers and views as you have tried in tutorials. This is to give you a starting point for your application. This is often enough for those textbook tutorials. For real applications though, you may not always have 1 domain class to 1 controller to 1 set of views. You might not always be doing CRUD operations on that domain. For this, you need to dig a bit deeper into Grails. You can do everything you previously have done in Spring MVC in Grails!
Here are some links to help you get going.
If you are trying to understand the 'flow' better. How requests get mapped to controllers/views, check out the UrlMappings.groovy in your config directory. Docs on that are located here: URLMappings
If you are trying to understand controllers better, check out this: Controllers. Keep in mind that your controller do not need to work on domain models. That is simply the default convention. They work similar to a Spring MVC controller.
Models are simple in Grails. Typically the controllers just return a map of the items you want to return. In Spring MVC, you often create a Model object, most times in Grails you will return something like [name: bean1, name2: bean2]. This allows you to easily get those two beans in the vies.
Start with 'Grails In Action'. The first chapter would give you details about the CRUD Sample app creation , but on reading further you would understand the grails flow better. Services are to be used for the logic, Controllers are used for delegation. You dont need explicit xml mapping as is done in Struts, Spring because everything here works on Convention.
Here is info on controllers: Controllers
Also you can use the same manual to find information on other stuff. For example about where to put business logic you should read in The Service Layer chapter.
Read Beginning Groovy, Grails and Griffon by Vishal Layka, Christopher M. Judd, Joseph Faisal Nusairat and Jim Shingler. They are building a real web application throughout the book with models, database access, authentication, css, templates and layouts, and many other things.