Have you worked with GraphQL? Saw it for the first time and it looks like a pretty good tool for working with APIs, to me. I am excited to read your opinions about GraphQL.

No but I'm favoriting this to remind myself to check it out later. Our current API sucks. Like, really bad.

@HollowKitty you really should. It's totally recommended for working with crappy APIs.

Yeah it seems pretty cool but basically I don't like the fact that the client can perform direct querying

@th4t well, he can't. You can setup an GraphQL-service on your website with endpoints, wich you can fetch from frontemd. And on this service you can configure your queries. It's a bit overingenieuring, but you can lazy load, catch and aggregate queries wich is really handy and also has good performance.

Its great, let frontend decide how and what data they want to get. Backend has their own datastructure which you probably dont want to force on others.

Graphql, more like "i fucking suck at dba"

@sharktits dba?

@Wombat Great

@Codex404 I think database administration but I'm still confused. If you run an API server, it's probably still backed by a database so you still need to do DBA. If you're a client of the API server, you don't usually have much of a choice about whether you get to directly access the DB or not.

@HollowKitty and even if you have full control over the database you dont want to write a query for every specific thing a client wants.

@HollowKitty @Codex404 I don't understand what you mean. Can you elaborate?

@Wombat it is a response to what sharktits said

@Codex404 I don't understand, why query for everything? Don't you use Views, stored procedures and functions?

I always do views then call it from sp or fn.

But then again, when I work with .Net I use Entity Framework and forget about queries

In-case of NodeJs I use mongoose but this means mongoDb only, and not everyone does that.

In the end just like a good developer designs his code to be reusable as much as possible, a good DBA/DB dev designs his queries to be reused and flexible as much as possible and not throw bunch of SELECT * FROM tblX

@gitpush that is completely true, but should a backend dev or dba decide what frontend can do?

@Codex404 tbh in that case I call it a mess.

Everything must be planned, and UI's are built based on scenarios/goal of building the system.

How data is structured inside database is not an issue for the UI nor how the UI is to be is not an issue for the database, the goal is UI wants xyz, db has xy, adding or removing must have no effect on the entire system because database is just a detail that can be replaced by anything, like a sudden change to use SQL db from NoSQL, only data access files to change nothing else.

From my point of view whenever I see a system that is controlled by what the UI might want/need I think it will fail soon, because UI knows nothing about data relation it should be built the other way around

@gitpush because a public for which the UI is unknown doesnt exist?

@Codex404 I don't understand can you explain

@gitpush I think you're confused. We're talking about APIs, not how the rest of the app should be structured. You can access an API from the server-side, which is what I do. In no way are we precluding MVC; we're just talking about what the API itself should allow.

Reusable queries are great and all but the minute you go beyond the most basic and common stuff, that falls apart. As soon as you get to anything like reports, the person writing the report code needs more flexibility in what to select.

At work right now we have ~10 different systems talking to one API. If we had to write a different endpoint for each use case, it would be a huge mess. It would be better if I could just say which entities I need joined together and which filters, basically querying on the API. Currently I can't, which means parts of the system that need this kind of data are querying more than they need and throwing the rest out. This is inefficient and slow.

@HollowKitty aah my mistake. But isn't that what OData is for? I know not everyone will use it tho, but you meant something like that for handling dynamic calls?

@gitpush If it allows those kinds of queries then sure -- but I've worked with lots of APIs in the past and never heard of it before. Why use OData and not GraphQL?

@HollowKitty didn't mean to make it sound as if: this or that

was just giving an example to see if I correctly understood your previous comment

@gitpush Ah then yeah, after some Googling I think OData would work fine. I don't even really care what is used to let me query what I need, I just wish it was possible. Most likely it'll end up being something shimmed onto of our existing architecture. :/

I like the concept of Frontend guy controlling data that's neat.

I hate that it uses only one endpoint, everything is POST, and result always 200 even on error, that sucks.

I am also getting the feeling it executes far more queries in DB than rest-like service where you control queries.

Overall I am still with REST.