Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
stop64553yhouses are never ready. everytime you are finishing something you find something other that can be better.
stop64553yevery programmer knows that programs are never finished. i really meant houeses(thirdlast point)
Is graphql really all everyone says it is? I cringe when I think of using anything Facebook had a part in. But everyone seems to love it.
@deusprogrammer Rest has serious problems when working with data that's not shaped like sets of raw database rows.
You can implement paging, and use request parameters for some filtering/selecting... but that's kind of where the standard stops.
If you want to know "The average age of users who listen to metal and live in a 30km radius of Berlin" you either have to ask the backend dev to make a super specific, new, non-resty aggregate endpoint... or slurp through all the stacks of pages of three endpoints and reduce it on the consumer side.
Graphql gives a bit more power to the end user to ask for intersected / constrained / aggregated results in a more efficient way.
Of course, that's particularly useful when you're questions are not about resources, but about relations, when your questions are "graphy".
BTW, lots of Facebook projects are MIT licensed. If you don't like that it's "theirs" — fork it. Then it's "yours". 🙃
That’s not true though, you can pass relatively complex queries through a REST endpoint as query parameters. And with NoSQL acting as your data layer, you can have your data fit any schema you want (even no schema what so ever). Granted the way queries are handled in graphql intrigues me a bit.
Scipio7033yMay I ask why you consider MySQL to be "insane"?
@deusprogrammer Of course you can... the problem is that when end users need very complex sets of data, implementation becomes less defined by the meager rest convention, and puts more strain on backend devs to come up with new, company-specific conventions. This often leads to inconsistent APIs, especially when a big team maintains it.
You could of course implement graphql yourself as resty query parameters — in a sense graphql IS just a good standardized protocol and extension of rest, defining how to handle common painful things like inclusions and filters.
MySQL has a lot of documented and undocumented quirks, and it's much harder to scale than most other SQL databases. Clusters don't always perform nicely, and it require a lot of query optimizations and database design efforts not needed in other databases.
Oracle is not putting a lot of energy in fixing small inconveniences and problems, and seems to actively prevent the community from getting involved (majority of code is open source, but they decline all patches).
If you compare MySQL to MariaDB, the former often feels like a hacky alpha version, the latter like a mature database, which is weird considering their ages.
If you compare MySQL to Postgres, the former feels like you have installed the trial demo version of the latter.
molaram45151yGet some ANC headphones if it's noisy @ your place
@dfox I don't mind seeing them, I think I mind seeing them sorted towards the top. I wanted to read week 200 rants, but when I clicked on the link, it's only week 100s for the first few.
It's also confusing since I need to figure out which topic they're responding to. Perhaps putting the date of a rant in the preview list (before clicking read more) would help.
Time capsule only really makes sense if the two topics are directly related. (How close was your week x prediction?)
stop64551y@dfox i have some ideas:
1. Some numbers are locked for old rants to prevent this. This could be problematic in this crisis.
2. We introduce a wkf (weekly future rant) for weekly rants about the future. Since not every rant needs a wkf the number wouldnt need to be synchron with the wk number.