>I have felt strongly that we would have been better off with a more boring approach like REST
What led you to this feeling? I know you want to hear from people on why GraphQL is good, but why would REST have been a better choice in that situation? I'm interested as someone who works with both day to day.
Thanks for your reply, I would love to hear more about which one you prefer in general REST or GraphQL, or if you have different situations where you choose one or the other and why.
Here were some of the things I noticed when comparing to REST:
- Caching can become a nightmare and requires a lot of effort to get working correctly for non trivial use
cases / you cannot really use the already "built in" cache control headers in the browser with GraphQL
- Another caching one, but you almost are required to have some kind of server side cache in addition to
the client side cache, it can quickly become disorienting trying to figure out exactly where something
is cached and why, or why you are getting stale data, etc...
- Some abstractions in GraphQL can make the code hard to follow / read in my opinion (data loaders for
example) and also make it hard to follow where the data is actually coming from especially in federated
subgraphs
- Error handling in GraphQL can be really unintuitive and more work is needed to not have the error
response come back as a 200 status code (or handle it correctly if it is an error inside of a 200)
The tone from the author is less complexity. It's a backend vs frontend debate. GraphQL can be magic from the client side but on the server side you have tons of boilerplate weighing you down.
Landmrk | React Developer | Remote | Full Time | Contract 3-6 mo to hire
We're a location based marketing startup: we've worked with some of the biggest brands, music labels and artists and launched global campaigns using our bespoke platform. We are looking to bolster our team in the short term to help deliver a fantastic project we've recently acquired funding for.
We're looking for someone with strong React skills, comfortable building PWAs and all things front end. Bonus points if you've ever got down and dirty with Ruby on Rails, likewise if you've worked with popular mapping libraries.
You'll be working with the CTO (that's me) and closely with the rest of the Landmrk team and our partners on this exciting new project.
Reach out to me at chris@landmrk.it - CVs are useful but not essential, Github profiles always good, but at least a short summary on your current/previous role and expertise would be great, along with any examples of your work in the wild.
Hello Chris,
I am very much interested in this role because of the skill match and I have worked for over 14 years in web application development and mobile application development. Let me know if you are interested in my profile.
I have few sample code lined up for you : https://github.com/chemalatha - few sample examples that i pratice.
This is a great collection. Lots of useful approaches, some of which I haven't seen before. Sure, some stuff wouldn't work for us, but that doesn't mean it's not useful to know about. Further reading section is also A++.
I really enjoy getting to influence projects at their genesis, being a CTO gives me a mandate to intercept & triage requirements. Trading off some day-to-day coding for this opportunity is a win for me.
I can't decide what to think about this pricing. Would a company pay $6k a year to almost not worry about hosting / ops? Actually, yeah, probably. Still seems like it's missing a lower tier though.
"What about a free option? We've always offered free hosting to every Meteor developer through our meteor deploy feature. It's never going away. Now that we've had a chance to shake out key parts of Galaxy's technology stack with large production apps, we're ready to transition that free meteor deploy service to Galaxy. We've already started on that work, so that every developer can use Galaxy free of charge for simple apps, or purchase smaller plans for projects that aren't a fit for a full commercial plan."
The difference is, Meteor won't have the volume of Digital Ocean or AWS, so they can't run on low margins. They need a high-margin pricing model in order to survive. The danger here is that high-margin pricing provides a high incentive for the largest customers to move to AWS, so they'll have to be sure to provide enough value to keep the big folks.
I think the difference in number of users is partly due to the asking price. I wouldn't use DO if they charged 50$ a month for a VPS to use for mocking up apps. For my use case, 5$-10$ a month is the most I want to pay in such early stages of development.
500$ a month is cheap when you have revenues. But when bootstrapping an app, it's simply out of the question.
Yeah, I'm so used to the pricing tiers used by Digital Ocean, Amazon, and Google Apps that I'm looking at this and going "Wait, the $995 a month tier isn't for enterprise?"
Everyone else is almost in a sort of pricing war, so it really feels very much against the current.
FTA: "every developer can use Galaxy free of charge for simple apps, or purchase smaller plans for projects that aren't a fit for a full commercial plan"
+1 If there's not a Meteor-specific package you're comfortable with then this is the option. Case in point, I prefer using stripe and twilio via meteorhacks:npm.
I've yet to come across a situation where something I wanted to do didn't a) have an existing Meteor package, or b) have an npm package that you can include using meteorhacks:npm by arunoda. I'm using Meteor for two enterprise-grade b2b projects (so: reasonable scale) and as far as I'm concerned the package ecosystem is freakin awesome.
For 1), the hardest part for me coming from LAMP stack apps was shifting over to the way routing works (see https://github.com/iron-meteor/iron-router) and attaching your subscriptions to routes.
FWIW don't use IronRouter. It's considered an antipattern now to tie your router to your subscriptions and generally to have reactivity in your router.
Use FlowRouter and BlazeLayout, both found on Atmosphere.
It's like yeah Martini is popular in the Go ecosystem, but it's now considered bad to use now that people know better.
What led you to this feeling? I know you want to hear from people on why GraphQL is good, but why would REST have been a better choice in that situation? I'm interested as someone who works with both day to day.