chrisquinnr

>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.

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.

https://landmrk.it

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.

I have, not ready for prime time yet as client is dragging their heels but the tech is sound. Using stripe, with big props to http://themeteorchef.com/recipes/building-a-saas-with-meteor...

+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.

For 3) I've used meteorchef's excellent base package (https://github.com/themeteorchef/base) for two big projects so far and it's great.