Absolutely. In fact I got this job by sending an email out to friends looking for something, but also offering to help out on stuff for free.

In case my meaning is lost, even if you know you're underpaid, you might be vastly underestimating HOW underpaid you are, like lots of people in my friends situation were leaving $40k on the table, literally more than 100% of what they were already paid. The guy next to you could be making double what you are. No one is going to tell you. You have to find out for yourself.

Would any of you cool kids still use REST over GraphQL for greenfield apps? Assuming standard web or mobile apps.

Edit: asking for a friend.

In my previous days as a programmer (PHP - turn of the millenium) I asked for and got a 90% raise after about 6 months.

Work or personal? What size team and what experience do they have with each? Whats the time frame, etc

So many factors, I'll just say graphql this is the graphql year apparently.

I'm pretty skeptical of GraphQL but I don't have extensive experience with it.

skeptical of what in particular? I have some issues, but in general feel quite positive about it

So I just assumed that GraphQL is obviously the future for standard apps given what I've heard without all that much experience with it. Then someone starting a new project was asking me about it so I just spent some time looking at the ecosystem and I'm really unimpressed - so many vendors trying to make money with a half-open solution and unclear how realistically interoperable all this is. It feels like most of the benefits only materialize once you have a relatively large codebase with a fair number of developers, at which point performance and on-wire type safety become big issues.

I guess I'd start here:
https://blog.goodapi.co/rest-vs-grap...w-5f77392658e7

I don't really agree with everything this guy says, like I don't think "true REST APIs" are that rare or complicated, but I've been doing this a really long time and maybe I'm underestimating how hard it is to get started.

The downsides of GraphQL that he brings up are huge things to me, i.e. scalability, performance, distributed-ness. The upsides are that it's "easy" which I don't care about and that it's "consistent" which I do.

However, when someone comes up with a scheme to help with consistency what they are usually leading you to is something with drastically reduced choice. The best way to make a language-type thing that leads to consistent client-server interaction is to limit the things you can do. SOAP, which he alludes to in his talk, is sort of an example of this. With SOAP, once you consume a WSDL description of a SOAP api, you can make a full client for it. That client is either going to be
* easy and consistent
* ****ing convoluted and tortured
pick one.

These automated systems in the past have led to vast abuses. I know way more about SOAP than GraphQL but it sort of leads to the same smell for me. The biggest abuse is that a lot of these systems allow turnkey ways to turn your Java or whatever library directly into an API, in the worst way possible. It reminds me of, god what was it, the tool everyone used to automate making library interfaces from C libraries to everything else (tcl, python, perl, etc).

SWIG, that's what it was. The guarantee was if you can get it to compile you'll have a library for your language that works and interfaces with the C library you wanted to target. But the only guarantee is that it will "work." It won't have any of the smoothness that comes with a library that was made by someone specifically for your language. The idioms with be the idiom of C. Type conversion will be done in the most pedantic and block headed way possible. Instead of wrestling with making a language specific library, they'll automate that part for you and instead you'll wrestle with the library itself. But writing a library is a one time pain, and using it is a forever pain. If all you need is a one-off simple interaction with the library, this is usually with it. If you want to do real work, it isn't.

All the above is really a criticism of all the things "like" graphql that I've dealt with in the last 20 years, plus what I've read about it. I haven't tried anything outside of toy systems with it myself.

And actually the backend part seems the like worst bits of ORMs to me. ORMs are the worst. They're a way for you to not use SQL so that it can generate the worst possible set of queries for any given circumstance. When you figure out why your performance sucks, then you have to learn SQL anyway, and then you have to figure out how to get your ORM to produce the SQL it ought to have produced but didn't, because it doesn't actually understand what you want.

I'm actually a fan of tight RPC-type systems, especially between a FE and BE that are tightly coupled with no expectation of 3rd party interaction. However, to make an RPC system that will work for everyone, you end up larding a bunch of complexity and configurability and what not onto it, and the result is ugly and fiddly and unpredictable.

So when I work on a project like this I usually start from something I've worked on before and gin up an RPC system that is specific to the system we're working on. Instead of being infinitely configurable it has just the things we want/need in exactly the format we want them. The result is code that's 1/3 the size and twice as fast, with most things being explicit, obvious and simple.

This is not very good criticism - GraphQL is absolutely battle-tested in these regards, probably more so than REST.

GraphQL is much more like SQL than SOAP and the automation layers around GraphQL are much more like ORM than braindead SOAP clients. If you want a throwback comparisons, you know how in the old days, people wrote desktop applications that talked directly to the database in enterprise apps? It's much more like that, without the security implications.

If you have things set up correctly, GraphQL is absolutely superior to REST both in terms of development experience and performance and at scale (in terms of # of developers, complexity of your application, and number of customers, etc), using GraphQL over REST is no brainer. I'm questioning the effort required to get to that point if you're just starting out, given that there appears to just one open-source solution that's battle-tested (Apollo) and it somehow doesn't even support SQL out of the box and its primary target appears to be a company with lots of REST services that's trying to simplify its complex API system into a single manageable front-end focused API. In its words:

And it's neither backed by a large tech company, nor is community-developed - it's instead developed by a small enterprise vendor who's going to have to figure out how to monetize this:

https://www.apollographql.com/plans

On top of this, it's unclear how well all these work together. Does relay modern work well with apollo-server? If I pick one of those graphql solutions in Java or .NET or whatever, would they work well with apollo client libraries? None of this is particularly clear to me.

What *does* it have support for? Mongo or some other nosql database?

ETA: and please don't tell me that I'm not supposed to care where my data is or how it's stored.

GraphQL is a significant improvement over REST in this exact regard because it's an actual query language, whereas REST requires translating natural queries into REST idioms. It's much more like writing actual SQL queries, while REST is much more like using a dumb ORM that uses precanned queries. Again, assuming you have good backend implementations.

Again, this type of discussion is not what I'm getting at, GraphQL properly used solves all these problems much better than REST and I don't really know anyone with sufficient experience with GraphQL that disagrees, assuming you have good implementations. It's unclear to me that the implementations out there are good enough or open enough without significant customization, whereas REST is extremely well-supported in just about every language/runtime.

It's just middleware, you're supposed to write your own.

Edit: it basically is what you're advocating for, you can write whatever sql query you want, with whatever ORM or non-ORM you want to use.

My own what?

I mean you're saying it doesn't support SQL, so I'm supposed to do what, convert graphQL queries to SQL queries? This is what I'm already doing with REST.

GraphQL seems to naturally support some things that I support by convention, like choosing which fields you want or controlling the depth that related objects get embedded, but I already more or less have to do this by hand, it doesn't sound like you're offering me anything better? Except that it's standardized I guess?

I've been involved in roughly 4 or 5 products that were supposed to provide a better interface to SQL and in every single one of them I just ended up wishing I was writing SQL queries.

I dunno, I am always wrong about everything but the more you describe it, the more I think there isn't actually anything there.

I interviewed at one startup that was in the process of ripping out all their GraphQL. I seem to recall some others that weren't nuts about it - while some were all in.

I guess I'm pretty religious but I want a clearly defined API and the theoretical ability to snap on a new front or back end at any time. Even if you almost never would do that - I think the exercise makes a nice separation and a clearly defined contract.

However - disclaimer - I've never really worked with GraphQL beyond tinkering and trying to get the gist of it.

Don't you lose a lot of tooling and basic things like browser debugging and stuff when you convert every request to a POST with some embedded query?

I get the "just starting out" thing - but how many serious companies are writing a pet-store type CRUD app where it's cool to have the FE more or less wired to the DB?

And if you do start out like that - you may have to rip out all your GraphQL when you need to add another layer or two. What good is having a natural query language when your middle layer is a bunch of service calls - which in turn talk to a bunch of lower level service calls - which eventually gets to a DB somewhere down the line?

Then again I guess if we're really doing true microservices where each service has its own pet DB - that probably makes more sense. Is that the plan for supporting a large system with GraphQL?

Rusty, totally agree ORMs suck. Never had a good experience with them going back to hibernate.

I was actually tasked with writing one for a big app at the consultancy I worked for. I kept it super lightweight - all it did was use Spring dependency injection to map Java objects to table inserts using reflection, and an apache commons library that converted rows to objects coming out of the DB.

The tables and columns all had naming conventions that coincided with the object names and properties - so if everything was named properly it just worked with zero configuration. But you could override them in the Spring config if needed.

The only other thing I added was a mapping table piece that returned/saved a HashMap of objects linked to other objects. Anything more complicated than that we just skipped the ORM stuff and went straight to SQL.

It was absolutely perfect for that app and tried to do about 5% of what an ORM would. It took me a week or so to write while an ORM would have been an endless hassle.

You're confusing implementation with standards. GraphQL is a standard. It doesn't do anything for you. I'm offering criticism of a specific implementation of GraphQL that happens to be the most popular. Standards aren't magically going to write SQL queries for you. I'm saying I'm underwhelmed by the capabilities of a popular framework and unsure that this would be particularly helpful for a solo greenfield type of project. With that said, if even a medium-sized organization adopts this, this isn't the part most application developers will have to spend much time with - they can build custom solutions around it. Thus, I can be against GraphQL for solo greenfield projects while being supportive of larger organizations adopting it.

I'm not offering you anything - I'm quite skeptical myself that the GraphQL ecosystem offers enough for a solo greenfield project and that was literally my point until you went on a tangent about how GraphQL is bad because SOAP and ORM are bad. But obviously in a large company, these problems are easily solved and GraphQL makes it easier to solve the problem once and use it everywhere. It's much better if you have a common standard and a common pattern for solving these types of problems instead of every developer creating a monstrous ad-hoc query language that supports all the features of GraphQL - which you literally appear to have done - except in their own idiosyncratic way. You answered your own question about why GraphQL is useful - Greenspun's Tenth Rule.

GraphQL vs REST is agnostic to the question of writing SQL queries vs using ORM in the backend. The critical distinction is on the client side - if you're the type of person who likes SQL vs ORM, on the front end, using GraphQL is more like SQL and REST is more like using ORM. GraphQL abstracts less and offers more control. Also keep in mind that if you're working with even a moderately complex product, you're dealing with layers of business logic much more than you're dealing directly with the persistence layer - and GraphQL is great for this as well, precisely because it abstracts less and allows clients more control over the precise query.

I don't understand this weird focus on ORM, nor this incoherent guilt-by-association reasoning where GraphQL is bad because it sort of kind of is like ORM and you don't like ORM. Also, just about every large complex application is going to have some layers that look like ORM, the only questions are where, how many and with what degree of specificity.

I'm not sure what you mean here. Are you saying that this is why apollo-server doesn't come with some basic SQL support? If so, I'd agree with that - it's an enterprise product aimed at large companies that already have a bunch of REST services trying out GraphQL and since their competition is REST they prioritized making wrapping REST calls easier. Which is another reason why I'm saying GraphQL may not be the best thing to start out with, mostly because the benefits aren't great for a simple greenfield project and the ecosystem is not great, with the most prominent vendor in the ecosystem being entirely beholden to enterprise support as the exclusive source of revenue.

The system you're describing doesn't seem particularly well-designed but assuming it is, one main benefit is performance - having the entire query upfront both reduces the number of end-to-end round trips and allows the backend to run multiple calls in parallel. Type safety is another - you can validate ahead of time whether your queries are valid and with some effort, it's also generally possible to figure out whether server-side changes would break older clients (I don't know how good the tooling is around this tho).

This derail aside, anyone had positive experience with apollo-server or any other GraphQL backend/middleware? Or on the client side, either relay, apollo-client or some other client? I'd like to recommend GraphQL if possible because I think it's the right thing in the long term but I'm just not seeing much - apollo-server being JS/Node-only is also a negative for my friend who's not super technical either.

Totally standard. Hell even companies will even do this. My one big contracting gig we gave a bunch of work away "for free". It was sort of a "You can sheer a sheep many times, but skin him only once" sort of situation (although in a good way).


I think ramp-up expectations are more reasonable in a regular permanent job, but I still think its good for career development to put in extra time when you're taking longer than you think you should be. This sucks, and I think it hurts a lot of people, but I think its also the way it is at lots of places.

Man Mongoose for my game app has been absolutely fantastic, easy to understand promise based way to do stuff to a collection with no worries at all.

So, basically this put me on the right course, thanks. I was working on that and today spent a while talking the guy who knows the system and he showed me how to just make it part of the node api and it is much easier than I would have thought.

Do you consume this over REST?