I am currently planning to create a library (I call it CRUD Library) that serves as an intermediate layer for a developer between his own code and the external UI/data-presentation library. The external library could be for example a library that displays lists or let the users manipulate lists (delete entries, sort, search etc). My plan is to create this intermediate layer that encapsulates the 3rd party library details and only exposes a simpler to use “CRUD” layer for most common use cases to speed up the development for most scenarios. I created a drawing to explain the idea in more detail:
The developer would this way be able to check if one of the templates provided already fit his user story (this would be User story 1 in the image) or if he would implement the outermost layer himself and use the CRUD layer (User story 2 in the image) or if his use case is so specific that he still needs to talk to the 3rd party library manually.
The idea is to find a few generic data manipulation patterns (that's why I want to call it CRUD library) that can be reused on any 3rd party library, so no matter how the 3rd party library defines its own interface I would want to expose a CRUD interface on top that the developer is already used to go use it instead. Similar to an Adapter pattern but on a library pattern level.
The template layer on top of the CRUD layer is an additional extension of the idea and it would, of course, be different for each 3rd party library but I want to research if also there I can find common patterns for very different libraries and target data structures.
My question is if anybody knows any existing projects or research in such a direction or has any other insights they might want to share, I am open to any feedback or critic, thanks!
Top comments (9)
Maybe postgraphile or hasura is what you are looking for?
Yeah, kind of. I think I was not clear enough. I am searching for similar approaches for UI libraries. So not for adjusting data on a server but to adjust the UI of the library used.
There a lot of solutions for the automatic or semiautomatic generation of CMS for Rails, for example:
From dev.to/stereobooster/headless-grap...
Actually, I don't quite understand, what the libraries are used for. Would you give me a short explanation?
What I understand is, so far, that they provide crud functionality on data using the UI when logged in as an admin.
But is it possible to just use, for example, adding data and disable the other features? So that users with different status can do different operations on the data presented in the UI?
Right.
I guess yes, but there is no single approach here. Each library will solve this in different ways. They give you CRUD, but it's up to you how to implement ACL
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...