I am trying to add a method available for all controllers in sailsjs, much like the blueprint methods are.
The method should also be exposed to a REST route (like /modelName/myBlueprintMethod).
How can I go about and do this?
I have seen lots of Qs for how to override the blueprint methods but what i need is extend the blueprint.
A little context.
What I want to achieve is to expose the schema of the model related to the controller to automate some front-end CMS.
Thanks
I also wanted a similar solution, although it would be a subset of your question: Asked a question here.
One way to go about this (and there could be others) is:
Make a service, send it the parameters and use it in all controllers.
Hope this helps.
I did mine as described here: OVERRIDE CRUD BLUEPRINTS.
I created the blueprint hooks in /api/blueprints/...
Related
I am learning jHipster. My entity relationship model has projects and files. A project can have zero to many files, and a file always belongs to exactly one project.
project <(1:1)-----(0:*)> file
Users interact with the application similar to using an IDE. First, after opening the initial website they always have to select which project they want to work in. (Of course they can also create new projects, or perhaps delete an old one.) Only then they get access to all resources added to a particular project such as files.
As a consequence, my REST API should logically look like this (to get a single file):
GET /projects/{:projectId}/files/{:fileId}
In the backend, depending on whether fileId is a UUID or not, I might even have a method:
findFileByIdAndProjectId(String fileId, String projectId)
The problem is that jHipster creates all entities in a "flat way". Each entity seems to have its own REST API without nesting, and there is simply a reference to an other entity rather than proper composition. Adapting the generated code is quite a bit of work as it requires lots of changes both on the frontend and the backend, but more importantly, it probably breaks the ability to re-create my code when an entity has changed.
I am curious: What different options do I have, and which one would you guys recommend?
Custom code is the way to go though there are few tricks that can help you:
Using DTOs so you can aggregate entities in service layer
Extending generated classes both in backend and frontend so that you don't change generated code, see excellent talk, slides and code samples from Antonio Goncalves
Does NestJS has built-in tools for CRUD generation like Loopback or Sails.js has? I really like the idea of NestJS but i don't want to repeat the same things in each Controller. I will be appreciative if someone could explain how can i reach it?
No, NestJS doesn't have this feature out of the box but you can use nestjsx/crud, It allows you to use all CRUD operation only by declaring an entity class. Check the getting-started page.
EDIT: now NestJS has a built in schematics, you can find a guide here on the trilon blog
I'd like to share my thoughts about https://github.com/swagger-api/swagger-node-express
It has 564 stars on Github, so I think it is justify to use it, but:
Why should I use methods like addGet/addPost and split my controller by HTTP methods
Why should I involve models to routing?
I can use validators for authentication, but I have to choose some paths, that should be protected there. It duplicates logic, that stores in swagger json file.
Isn't the right way to have a static swagger.json and build Express routes on it?
Or maybe I don't understand some practics
Swagger is just a spec. You could hand craft a swagger spec without any code, serve the spec to a swagger-ui compliant page, and it "will work." You could have a fully defined API and "run" it using the UI pages. Same is true for Express without swagger - you can do a lot of neat things! But some effort would be needed to document the API in swagger.
If you want to use swagger-node-express, you are coupling the code to the API documentation. This can save you a lot of time, and keep changes in the same file, etc. However, like all your questions allude to, you must do things the swagger-node-express way. Faster than doing both separately, but there are constraints one must follow.
There are other swagger packages that tackle this from different angles. I've seen some that try to build the swagger docs from the Express/Restify routes automagically. An alternative to swagger-node-express is swagger-tools, which even includes validation, but I'd guess you'd be limited in some fashion to writing Express without any swagger integrated.
You are free to build swagger docs manually (or with some YAML, jsDoc package or a generator), but that would take some extra time after your routes are written. Plus, it's a separate place to maintain your docs and invariably they will be out of sync at some point, if not abandoned. Using swagger-node-express is primarily a time saver and, even with its drawbacks, that might be worth the extra development effort of the alternatives.
I've been using SailsJS for a while now and find it a perfect REST API solution. I'm currently building an app for both Web & Mobile (native) so I need the REST part of SailsJS. I want to build a frontend for my API right now, and I found EmberJS which looks like a promising framework. I've a question about combining those two, they both have their own Routing system, and SailsJS seems to overrule Ember's one.
My guesses would be:
The most easy approach looks like building Sails in a subdirectory
eg. /api/ but I think that's not the nicest way to get this fixed.
I could choose one framework for routing and let the other delegating it's routes. For example passing parameters from SailsJS through EmberJS
How can I use those together correctly?
Think of your backand as something you can't control, like a 3rd party API. The reason is that the optimal routing for a user may differ greatly from what's considered to be good API semantics. It's also not easy to share the route declarations, but it's not a good practice anyway.
My advice:
Use ember-cli to build the frontend. It's a great tool, you'll enjoy it a lot.
Build your Sails-based API in a different repository, using the /api namespace for your API endpoints.
Try to follow the JSON API standard as closely as possible. That'll make easier to connect your backend & frontend, as most data libraries (Ember Data for eg.) tries to adhere those standards as well.
Watch Luke Melia's excellent guide on lighning fast deployment. It'll be the same concept for you but in Sails intead of Ruby/Rails.
All in all, I think if you'll have a great dev experience if you do roughly what I've outlined above. Happy coding!
We have been looking closely at SPAs using Breezejs for providing the data context between the client and the server. The features look great on the client, but we want to use the Repository pattern on the server and get good separation of concerns without having to inherit from EFContextProvider which would cause problems with IoC and possibly unit testing/mocking. We have been following John Papa's Code Camper sample on Pluralsight which initially set out using a Respository/UoW pattern without Breeze which then led us to look at the Hot Towel template which does include Breeze.
Does anyone know how Breeze can be abstracted to a Repository which keeps the DbContext cleanly (if using Entity Framework) encapsulated. Also, what happens if you are not using Entity Framework and prefer to use another ORM such as nHibernate.
Thanks for posting here as I am sure others will ask this :)
If you don't use EF then you won;t get the automatic metadata creation that Breeze provides. You can certainly abstract the EF context into a Repo however, and still get the benefits.
The Breeze/Knockout ASP.NET SPA template shows the repository broken out. I believe there is a sample for the UoW somewhere - tho it escapes me where. I have asked the Breeze folks to point to an answer for that.
If you use nHibernate there is no automatic metadata - however that is a great feature request I could see for Breeze.