#Patterns Service layer and naming conventions

[Dr4gon]

@Marwerk As promised the very simple introduction to service layers. The purpose of these additional layers is to encapsulate more sophisticated operations on the model layer and provide a clear implementation of your interface to e.g. the frontend.

Simply said: You're already using them under your route folder in the backend. An additional benefit of renaming bookings.js to bookingService.js will be a clear separation to bookings.js which sound's nearly the same. And so and so forth.

What I would additionally do - depending on the size and design of your app - is to offer pure interfaces that define the API contract between backend and any other code that's using these interfaces. Thus allowing a versioning of the interfaces (different android versions for the phone) and a separation of the actual implementation = service from the interface. Enabling loose coupling, easy maintenance and just in case the possibility to replace the services underneath.

References:

• https://angular.io/guide/architecture-services
• https://java-design-patterns.com/patterns/service-layer/#explanation
• https://stackoverflow.com/questions/3710275/does-javascript-have-the-interface-type-such-as-javas-interface

[mai-soup]

@Dr4gon I was under the assumption that, in the backend, the service layer should be framework-agnostic, i.e. in our case not depend on either Express or Mongo, and was what Armagan said when he talked about the classes with methods, which we have in our model files, being interfaces independent from Mongo/Mongoose - we could extract them into separate files to be our service layer.

So, we could separate our current structure into route handlers, controllers (optional I suppose but to me it makes sense to separate that concern out too), services, and models. Route handlers only pass an incoming request to the appropriate controller, which extracts the data from the request and passes it on to the service layer. That then processes it, interacts with the models as appropriate, updating them etc., and passes the result back to the controller, which returns a response to the route handler.

As route handling depends on a framework, in our case Express, I thought it doesn't belong in the service layer (why would it appear in our classes that we attach to our models? that makes no sense). And technically we already have a service layer, it just lives in the same file as our data structures. Am I wrong here?

[Dr4gon]

@mai-soup What u want to achieve is nearly impossible in JS because it doesn't provide interface contracts as other languages do: https://stackoverflow.com/questions/3710275/does-javascript-have-the-interface-type-such-as-javas-interface . The moment you try to make it "independent" you'll still end up transfering some of framework specific habits to the other class. In Java I'm able to build an interface against which I build a test suite regardless of the implementation behind it. Thus allowing me to truly seperate the actual used framework from my service layer.

Of course, you can extract controllers, too. In that case the naming to me would be off because it only transforms data to be used in routes. Even on return the route handler decides about what to do with the given data.

What's the difference if the service layer depends on Express or in your example to the model there to Mongoose?

[mai-soup]

Alright, at this point it's obvious I've either misunderstood or am misremembering what Armagan said about service layers and controllers. Was hoping I could just @ mention him here, seems not 🫠