It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Maybe think of this: Most of the developer wants the possibility to add, delete and change the data. Every developer implements them themselves when using the library, but implementing them once and stack them on top of the library reduces the time of the other developer as they can use your functions for deleting, adding and changing.
You have just described what a service layer does :)
Data access libraries and frameworks do tend to offer a lot of potential ways to solve any given problem, since, after all, different organizations may need to approach the same problem in different ways. A service layer defines how particular problems are solved for your organization: retrieving a list of users, for example. It's easy to just use your data access tool to pull that directly out of the database! But if you have a larger team or a larger project, you need to start setting standards to avoid confusion: this is how we get a list of users, with this role and permission information, filtering by that field to ignore soft-deleted accounts, and so on. And once you've defined a standard, you can add a mediating layer in between the data access toolkit and your different developers' different user-facing endpoints.
This is how these things tend to evolve as teams get larger and scopes widen (there's a wealth of literature on imposing formal structures from the top down too, but they all more or less reduce to variations on this theme of mediating layers between users and data):
database <-> front end
database <-> data access functionality <-> front end
database <-> data access functionality <-> service layer <-> front end
You're at stage 2, and your project size and/or team size mean it's time to think about getting to stage 3.
This is not a general-purpose intermediate library, although extensibility and future-proofing are concerns you should at least remain aware of. But you are guaranteed to have certain needs and assumptions about your parameters and outputs which are not universal, so it's a project you should approach with your product(s) and your database(s) first in mind.
Yeah, what I'm searching for is similar to the service layer you described. But, my intention is not to provide functionalities to change data on a server but to provide those functionalities for a UI library. I'm sorry if my intention is not clear enough...
Maybe the best example I can think of is the leaflet distortableimage library providing distorting images. They already implemented functions for deleting, rotating, scaling and distorting images and the developer can choose which options he likes. The functionality is then only done on the UI layer but not on the data layer. This is more what I am thinking about.
Ressource: github.com/publiclab/Leaflet.Disto...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You have just described what a service layer does :)
Data access libraries and frameworks do tend to offer a lot of potential ways to solve any given problem, since, after all, different organizations may need to approach the same problem in different ways. A service layer defines how particular problems are solved for your organization: retrieving a list of users, for example. It's easy to just use your data access tool to pull that directly out of the database! But if you have a larger team or a larger project, you need to start setting standards to avoid confusion: this is how we get a list of users, with this role and permission information, filtering by that field to ignore soft-deleted accounts, and so on. And once you've defined a standard, you can add a mediating layer in between the data access toolkit and your different developers' different user-facing endpoints.
This is how these things tend to evolve as teams get larger and scopes widen (there's a wealth of literature on imposing formal structures from the top down too, but they all more or less reduce to variations on this theme of mediating layers between users and data):
You're at stage 2, and your project size and/or team size mean it's time to think about getting to stage 3.
This is not a general-purpose intermediate library, although extensibility and future-proofing are concerns you should at least remain aware of. But you are guaranteed to have certain needs and assumptions about your parameters and outputs which are not universal, so it's a project you should approach with your product(s) and your database(s) first in mind.
Yeah, what I'm searching for is similar to the service layer you described. But, my intention is not to provide functionalities to change data on a server but to provide those functionalities for a UI library. I'm sorry if my intention is not clear enough...
Maybe the best example I can think of is the leaflet distortableimage library providing distorting images. They already implemented functions for deleting, rotating, scaling and distorting images and the developer can choose which options he likes. The functionality is then only done on the UI layer but not on the data layer. This is more what I am thinking about.
Ressource: github.com/publiclab/Leaflet.Disto...