I am developing a Nodejs application and my database is Postgres and I am using Sequelize as my ORM because of its excellent support for migrations.
I am on the lookout for a good REST API generator based on the schema I have defined. There are two main hurdles I am facing and they are that the generators don't do a good job of creating association API routes and lack of ACL support.
On the associations front, my schema has multiple levels of association i.e. for example..
Student.hasMany(Courses);
Courses.hasMany(Subjects);
So ideally the generated REST API should be something like
/student/:student_id/course/:course_id/subject/:subjectId
I found a few projects that are doing this, but are incomplete.
https://github.com/sequelize/sequelize-restful - is good but does not have ACL support
https://www.npmjs.org/package/restizr - is in alpha stage and does not generate API routes for associations.
Is there any module that supports this?
What you were doing here is writing a webservice without a domain model. https://en.wikipedia.org/wiki/Anemic_domain_model Ofc. you have every right to do it, but I wonder if you really understood what a webservice means. https://stackoverflow.com/a/1530607/607033 It is not a database with CRUD HTTP interface normally, though nowadays it is popular doing something this way and call it REST. A response to a REST HTTP request is a viewmodel https://softwareengineering.stackexchange.com/a/425001/65755 and it contains not just data, but a lot of metadata and hyperlinks. A REST API is a special type of webservice with many constraints. https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf http://www.markus-lanthaler.com/research/hydra-a-vocabulary-for-hypermedia-driven-web-apis.pdf Your ORM is used 2 layers deeper in the data layer and it has nothing to do with the presentation layer where your REST API should be. I really wonder why people are making applications, which are doing nothing except serving data directly from the database and use the most inconvenient technology to do it. I guess there are databases nowadays with ACL and REST API support, so all you need is just using them. https://learn.microsoft.com/en-us/rest/api/sql/ Or there was something for PgSQL and Nodejs too around the time you asked this. https://github.com/QBisConsult/psql-api
Related
I'm working on a project that require API that does not exist yet (I thought I would never be in this situation... :D) - so I have decided to build my own.
I'm using MongoDB as a database, Node.js, Express.js as backend framework,and Mongoose as ODM tool.
It's very simple API, all I need is 3 get routes:
GET example/random-item
GET example/all-items
GET example/some-items/:limit/:skip?
And one more thing that I need is a way to post new items to the API:
POST example/add-item
How can I make sure, that I will be the only one, who can access this route?
I want to be te only person that fan maintain the API, users can only GET data, they cannot POST data.
How does it work in a real word, when someome is maintaining some bigger API with more routes and more data?
Kind regards,
Bartek
Why should I use graphql if I setup a react frontend and mongo db backend?
And Why should i put graphql server between mongo db and react?
Since you didn't mention what is your alternative API style I will just assume it's REST. GraphQL gives you many features a plain old REST api won't have out of the box.
This is probably the best answer listing advantages and disadvantages of both.
You already have validation(via mongoose schemas), but using GQL you can get:
excellent documentation for your API generated for you
avoid underfetching/overfetching on frontend
ability to batch FE requests easily
you can tap into a very rich ecosystem of GraphQL tooling which only gets better as time passes
easier testing-you can just execute your graphql queries on backend even without sending them over the network saving a little bit of performance overhead
I believe you should use GraphQL for any non trivial API, because it adds ton of typesafety and the price you pay as a developer is very low.
Imagine I have an angular project as a front-end which communicates with some other projects which are restful services.
In some pages I need to fetch some data from different restful services,
Is that okay to request any restful service individually in angular?
Or call one restful service which itself call other restful services in back-end?
Or I have to call one restful service but add other entities to this DbContext which I need here just to query?
It depends on what you're doing, but I would say mostly it's OK to do this. This is an established microservices pattern called "Composite UI". See this for details: https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout
If your microservices are using the CQRS pattern, (while still not wrong) you may be missing an opportunity to compose a view-specific "view model". However, if you're composing\showing data from multiple domains I would say that it's still better to just call multiple microservices to retrieve the data you need.
The only problem you may be introducing if you're not careful, is introducing projection logic (which is not THAT bad) or business logic (very very bad) in your client code if you're doing any processing on the data you receive in order to display it. Composite UI is meant to server a UI with clearly separated sections.
I'm looking into node.js which really seem like a pretty nice environment. I've worked with a lot of different Technologies and for server, mainly php and Java (jsp), but dabbled in som RoR and Python.
I find node.js really easy to get up and running and it feels quite natural to work with, and I found some good entry level tutorials.
I just am missing some more intermediate resources. For example when creating bigger frameworks or api's how would you structure or architect it. I set up some smaller api's to try it out where it would go something like this:
I've made use of the Express framework to create a http server, listen to a port, set up an express object and bound some requests.
However these have been quite small, and the purpose has been learning, if I think about scaling up the size of the API for production, perhaps wanting to do other stuff like serve web-pages as well. I find it hard to see how the architecture would look.
It's vague as I am still new to node.js but I'm mainly thinking about things like if you typically keep all api in one file or if there are good ways to split it up into modules? And if anyone know any resource talking a bit more about how to design the architecture when working in node.js
Sorry for the vague question and thanks for reading.
In my opinion, Express is the good way to go if you want to build complex or big APIs.
It is among others easily testable (for instance with Mocha or Jasmine) and customizable, especially thanks to its middlewares.
For the directory structure, what I usually use is (at least) the following:
app.js : the main entrypoint. Will create the express application, indicate which controller to use for every route prefix, and assign the middlewares. Example from a previous project
controllers : will contain the controllers, the functions which will handle the requests, in the same style as in standard MVC frameworks (e.g. UserController, ...). Each controller would create an express Router object and export it. Inside the controllers, individual handlers are in charge of individual API requests, such as /api/users/list. It would use some library to access your data (e.g. Mongoose for MongoDB), and would then send the response to the client. Example (UserController.js)
models : will contain the models with all their attributes and methods. In my case, it would be the Mongoose models. Example (Song.js)
middlewares : will contain the various middlewares of the project. A practical example would be a middleware checking for an access token in the incoming request, and returning a 403 HTTP error if not. Example (AuthMiddleware.js)
helpers : various helpers
tests : unit tests of you API
This could be the minimal directory organization. On top of that, you may want to use a templating engine such as EJS to serve webpage. Take a look at « Use EJS to template your node application ».
This is only to give you an overview of what an express directory structure could look like, but there are of course plenty (better?) other possibilities. Hope that gives you a quick and useful insight :)
I'm researching BreezeJS for a big upcoming project.
Our goal is a offline first web app.
But here is what I can't fully understand (and would take to much time to test) - Does BreezeJS allow for the backend to be a REST API (built with NodeJS and Express)?
We need this because we don't want to simply sync to a remote DB (in our case Mongo), but use a remote REST API so that we can embed some business logic. Things like workflow triggering on a POST to a particular entity.
Is this possible with BreezeJS? If not what would be a good option?
Thanks in advance
It is certainly possible, simply take the breeze-mongo server implementation and strip out the mongo specific code. This should be fairly straight forward, express and mongo are pretty well separated in the code.
That said, you would lose or have to rewrite much of the server side code that converts an OData query string into a mongo query, but if you are going pure 'REST' you probably don't want that anyway.
You would have to do something similar on the save/POST side, but this is presumably something you are already familiar with.