> A central point of REST is that any resource (e.g., user) can support an unlimited number of different representations. This isn't just true on the level of, say, XML vs. JSON but also formats which embed and do not embed subordinate/related entities.
I'm aware but how does that work in practice? actual implementation wise. What does the formats to include or exclude related/nested entities look like? how do clients use these formats? also how does supporting embedding multiple levels of nested entities work in this pattern? I asked all of this because I don't think I've seen this implemented well without a convoluted in-house implementation of a query language like GraphQL's shoehorned into query strings. A specification is only as good as the people implementing them.
> How are query strings a workaround and not a declarative mechanism?
In simple cases, they can be. But they are very limited. How do you express in query strings the exact data fields, nested entities, and shape the client wants to retrieve? (this question might be related to the questions above)
> I mean, it would be better if HTTP had a verb that was like GET with a body so that you could define one or more media types that could be used to specify details of the resource representation sought, and that's what the QUERY draft [0] is about.
I didn't know about the QUERY draft. This is very interesting and would be great to have in HTTP. This is a good example of the gaps in HTTP that technologies like GraphQL are trying to fill.
You can definitely shape the data in any way you want with REST. You can find parallels with GraphQL features and REST and you can argue for either way because its 1:1 comparison. Comparing technologies requires looking both at a 1:1 level and as a whole.
But with your nested relations example, wouldn't getting a user always return its nested relations?
- what if a post has its own nested relations? some pages might need just a user's posts without the posts nested relations and some pages might need them all.
- what if a page only needs user info and doesn't need the user's posts?
With both similar scenarios, you'll need a way to communicate that to the user endpoint so it knows when and when not to return its nested relations and how deep. You could do that with query params sure but IMO that's a workaround with what the frontend really needs, a declarative way to let the API know that for this specific request, this is the exact data I need and its shape. No more no less. With also the flexibility to get everything in another request. You could also do nested resources with REST /user/posts/categories and /user/posts/etc but then that's multiple calls to get what you need. With GraphQL, these scenarios can be solve with a single API endpoint and single requests to it.
Also the productivity gain from GraphQL is actually more apparent in smaller eng org compared to a massive one. That's because for GraphQL to be at its best it requires the people implementing the schema to work closely with frontend folks. Even better if they are full stack and are the same people.
GraphQL APIs that are public will usually have a less than optimal dev experience because it has to consider general and unknown use cases. GraphQL shines when you control the API and the frontends that consume it. This is mostly because the schema design will reflect the exact use cases the frontend needs. So the data and its shape and its mutations are exactly what the frontend needs. You can't really do that for public APIs because you don't really know or predict the use cases for 3rd party frontends.
Then that's a problem with the schema implementation and not necessarily a fault of GraphQL. The people implementing a GraphQL schema should be working very closely with the people working on the frontend and put a lot of importance on how they want to consume the data.
GraphQL schemas that basically just expose the data models 1:1 without considering the exact workflows the frontend needs is a terrible implementation and misuse of GraphQL. Might as well just expose the data using REST
Not going to lie, before I visited the site, I was hoping it was a hot take article about why Ruby on Rails now suck and people should stop using it and migrate off of it. I was ready for the comment section.
I don't get how "layers and layers of abstraction/concepts that are hard to grasp for a newcomer" is your critique here? The literal entirety of tech is layers and layers of abstraction. Also, just because the improvements or new concepts are going to be difficult for newcomers to grasp doesn't mean they are objectively bad. The fact that things are going to be difficult for newcomers should not be an impeding factor on whether or not to build upon existing features. There are ways for newcomers to build up their way to eventually learn the advance concepts. Newcomers are not forced to go from 0-100 on day 1
You don't need something like React for building rich GUI today but once you have a sufficiently large codebase and a large team of developers, you're going to end up building inferior in-house versions of libraries/frameworks like React/Redux just to have any sane structure in maintaining the application as well as support future feature development. The currents state of front-end is complicated but I absolutely prefer it over the chaos of old timey vanilla javascript.
Of course. I didn't say Next.js solves the complexity of building a massive product, no framework will prevent complexity at scale. That's my point since this thread seems to put Rails on a pedestal like it was the main thing making products built with Rails simpler compared to other frameworks in other languages when in reality, the product requirements are most likely pretty simple
Over-engineering is not exclusive to the JS world. It's just in the spotlight nowadays. Rails also just hides its magic well because of Ruby and most experienced devs are already used to the Rails magic so its simpler compared to the new stuff like Next.js.
Eh. Perhaps you're looking through rose colored glasses on the days of Rails dominance? I've worked at multiple companies using Rails and not one was simple. Especially when you have 100+ engineers working on different aspects of a massive product. Anecdotal but Rails has a ton of magic to make things work but its only simple if you're product is a super basic CRUD app
Your advice is pretty good but it only really applies to junior level roles.
If you’re applying for mid level up and the only relevant experience you have for the role is a github profile with side projects, thats not going be enough to get an interview. Recruiters who screen candidates won’t even check out github profiles let alone evaluate their content.
Degrees are not really a hard barrier nowadays to get interviews. What’s important is relevant experience. OP doesn’t sound like they have relevant professional experience to the roles they’re applying for. which is probably why they are not getting interviews and is incorrectly blaming their lack of degree as the reason
Not a single interview? That’s got to be a incredible amount bad luck because it’s a pretty hot market right now for SWE.
Like I’m a high school dropout who also doesn’t have an active online portfolio and I currently work as a SWE at a tech company but I’m on a search for a new remote role in the last month or so and have done multiple interviews for remote roles. Even FAANG recruiters have reached out for interviews. A lot of job postings don’t even list a degree as a requirement or nice-to-have.
Are you only missing a degree when you look at job postings? Because while I do think there are companies who filter out candidates who don’t have degrees, I don’t believe that it’s a hard barrier nowadays to not even get a single interview.
If you’re missing all of the requirements how do you know you can do better than most of the folks who have the role? Seems odd to bring down the folks who have the roles you’re trying to get
Interesting tone of discussions happening in here compared to the same post in reddit.com/r/programming. The comments in reddit seem to be geared toward how this isn’t a replacement of a CS degree with a hint of elitism. I mean, I agree this is not a replacement for a CS degree but they all seem combative and hostile towards people wanting to learn CS concepts via alternative means
Sure, but that’s a terrible experience. Especially for a language marketing itself as simple. And just because you can “go-to-definition” to see where the dep is stored, it doesn’t answer questions like does every project dependency get stored there? What happens when another project somewhere locally has the same dep but a different version? Can you have deps locally stored in your project folder? All these can questions can be googled of course :)
IMO I think that section in the docs is missing quite a bit of things when it comes to module resolution. I had the same issue when learning Go. It was quite confusing trying to figure out the node_modules(JavaScript) or _deps(Elixir) Go equivalent.
I'm aware but how does that work in practice? actual implementation wise. What does the formats to include or exclude related/nested entities look like? how do clients use these formats? also how does supporting embedding multiple levels of nested entities work in this pattern? I asked all of this because I don't think I've seen this implemented well without a convoluted in-house implementation of a query language like GraphQL's shoehorned into query strings. A specification is only as good as the people implementing them.
> How are query strings a workaround and not a declarative mechanism?
In simple cases, they can be. But they are very limited. How do you express in query strings the exact data fields, nested entities, and shape the client wants to retrieve? (this question might be related to the questions above)
> I mean, it would be better if HTTP had a verb that was like GET with a body so that you could define one or more media types that could be used to specify details of the resource representation sought, and that's what the QUERY draft [0] is about.
I didn't know about the QUERY draft. This is very interesting and would be great to have in HTTP. This is a good example of the gaps in HTTP that technologies like GraphQL are trying to fill.