Having worked on Dev tools for more than 6 years, I have written my fair share of abstractions. We try to abstract much of the complexities needed for developers using our framework / library to have to worry about. I have heard of this complexity referred to as "plumbing". But thinking about it more lately, when does abstracting too much from developers become a detriment?
Take GraphQL as an example. GraphQL is a way for front end developers to query the backend for just the data they need. It also provides a caching mechanism so we as developers do not need to think about it. As a front end developer, we just need to know how to write our query so that the backend can understand how to fetch the data. On the backend, resolvers are written so that it can give that data to the front end. So on the front end, all of the logic of the orchestrating the data is abstracted from us. (There is not really any difference here as using RESTful endpoints other than we now only need to call one endpoint to get all the data we need). On the backend, all the data is orchestrated to be sent back via the resolver function, so no real abstraction.
Now, let's go ahead and add Prisma to the mix. Prisma provides an ORM type of layer on top of GraphQL. It gives developers a way to get access the database to create the models that can be used in the GraphQL queries by creating the models from the database tables and relationships. It also provides a pattern for writing the resolvers. This "magic" is all accomplished through a simple CLI command.
But "magic" comes at a cost. Abstracting all the "plumbing" may make rapid development easier but it also removes the developers to have to think about how things work. It becomes a black box. The problem with black boxes are that when they break, getting insight on how to fix it becomes extremely tough. It also makes all the decisions for you. There are usually ways to override the decisions, but it feels much like you are hacking your way around.
Here we just talk about GraphQL and Prisma, but it is prevalent in the ecosystem today. From lower level abstractions like front end frameworks to higher level abstractions like low code / no code software like Webflow. As someone whose first website was written with the WYSIWYG editor Microsoft FrontPage, I think that lowering the barrier on entry for newcomers to the industry far outweigh the perils of not knowing exactly how something works. From personal experience, I know that having the details abstracted from me as I was using FrontPage to fumble around dropping in images and using the font selector build my first website, it sparked an unquenchable thirst to learn more. It lead to me wanting to learn the spaghetti that was ASP and VBScript. And here I am, still learning and loving it 20 years later.
Top comments (0)