I'm building an app using express and mongoose. My backend is an api (since the frontend is native iOS). In an MVC framework, the controller acts as an interface between Model and View. Since I don't have Views, should I do away with the Controllers and keep my crud operations in the Models, or should I keep them in the Controllers? What are the pros and cons of each approach?
View
You still have a view since you'll need to display whatever the response is.
CRUD operations
These operations are delegated to the service layer by controllers. The service layer alters the state of the model layer.
Related
I have a nestjs application using DDD.
I have following folders:
Domain
Application
Infraestructure
I have the use case of scraping information from youtube channels. DDD is clear to me if I end up saving things in the database. But if I am only scraping? once the scraping is finished, then I would have the use case of saving in the database
Application
use-cases
scrapChannels.useCase.ts -> instanciates the youtubeLogsRepository interface in the constructor
Domain
entities
ports
repositories
youtubeLogs.repository.ts -> interface with getYoutubeLogs() method
Infraestructure
adapters
presentation / http / controllers
repositories
youtube-logs
youtubeLogsScraper.repository.ts -> here the logic to scrap
I placed the logic to scrap in infraestructure, but not sure if it should be in the domain. Also not sure if it should be under repository, since it's not touching the db. If not, then where it should go?
I have a background with a spring boot, but I started learning NodeJS (Express). In Express, the business logic is included in the controllers and there are no services, but there are routes, that resemble the controllers in Spring Boot.
Which components represents the controllers, services and repositories in Express?
For example, in spring boot, the request parameters are validated in the controller and the business logic is executed in the service. However, in Express I have the feeling, that the both operations are done by the controller.
Is there a cheat sheet for express as a Spring Boot developer.
Designing the flow and structure of your backend is up to YOU as a developer – not the language. Nothing is stopping you from designing a backend using express where the request parameters are validated in the controller and business logic is executed in service files. As a matter of fact, every Express API I have built follows that exact process.
I'll link an API that I created, but feel free to use any of the following resources:
https://github.com/sidd-mittal/REST-API
https://www.freecodecamp.org/news/rest-api-design-best-practices-build-a-rest-api/
TLDR; building you're API structure is language-agnostic, choose whatever suits your wants and needs.
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.
In a typical MEAN stack application, the server side have Model, View and Controller, where the Model represents the mongoose model. Suppose that, the application does not access to database directly, rather it is accessing the database via RESTful API, is there any model representation in this case? If yes, what is the model representation?
There are various processes which run sequentially when we do some kind of operation using mongoose. Calling statics, methods, data validations, pre-save hooks are some of them. Now, for a REST API accessing DB there are ways to create these processes.
Let's say we are doing operations on users -
Create a service which can validate all the data of a particular user (req.body) using a validator such as validator.js
Create methods in that service which can serve as statics or methods same as they are created in a mongoose model
You can also create pre-save hooks (method which is always called, like hashing password) if necessary before sending your data through the REST API
It is possible to create multiple services to validate and modify data as and when necessary in a very nice way by calling them in an order at your route middleware.
For example -
router.post('/users', [
RestService.getUserById,
UserService.checkForDuplicateUser,
UserService.validateData,
UserService.preSaveHook,
RestService.saveUser
]);
So in this way a model representation can be created.
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