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.
What you're saying is that the third-party data access library you're using is so poorly-suited to your needs that you're considering writing a complicated wrapper and snippet library assemblage to make working with it tolerable.
Is this really the best use of your time and effort?
Could you solve the issue of the same data access patterns popping up here and there by factoring them out into a more centralized service layer instead?
Is there a third-party data access library for the language/platform you're using that does something closer to what you want?
It's not that the third-party library used provides too little functionality. More often it provides the possibility to code many different functionalities. When implementing for a special use case some code is written especially for this use case. When another use case needs to be considered, then sometimes a lot of time is needed to implement this new functionality.
My idea is to save time on coding because the main functionalities are already implemented. These should consider most of the use cases and the developer can choose between the given functionalities so that they suit the developers' needs.
I don't quite understand your second question..
And regarding your third question. I don't want a library fitting one special use case. As I said, the library should have the possibility to fulfil most of the use cases so implementing the "CRUD" functionality should only help to reduce written code by the developers.
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.
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.
What you're saying is that the third-party data access library you're using is so poorly-suited to your needs that you're considering writing a complicated wrapper and snippet library assemblage to make working with it tolerable.
Is this really the best use of your time and effort?
Could you solve the issue of the same data access patterns popping up here and there by factoring them out into a more centralized service layer instead?
Is there a third-party data access library for the language/platform you're using that does something closer to what you want?
It's not that the third-party library used provides too little functionality. More often it provides the possibility to code many different functionalities. When implementing for a special use case some code is written especially for this use case. When another use case needs to be considered, then sometimes a lot of time is needed to implement this new functionality.
My idea is to save time on coding because the main functionalities are already implemented. These should consider most of the use cases and the developer can choose between the given functionalities so that they suit the developers' needs.
I don't quite understand your second question..
And regarding your third question. I don't want a library fitting one special use case. As I said, the library should have the possibility to fulfil most of the use cases so implementing the "CRUD" functionality should only help to reduce written code by the developers.
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):
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...