jgj

Location: Eastern PA

Remote: Yes, preferred

Willing to relocate: Yes, but would rather not

Technologies: Typescript, Node, React, Vue, C#, SQL, GraphQL

Resume: > 10 years experience, full stack. Previously @ Amazon, currently @ Toptal.

Email: [email protected]

with PostGraphile you pretty much are in complete control. You're free to write your own postgres functions/views which postgraphile will expose as endpoints. you can do so such that they are standalone endpoints or sub-queries to the auto-generated table queries. you can also basically bypass all the auto-generated table queries by creating them in a schema that postgraphile doesn't introspect, and then write all the functionality you want in a schema that it will, thus getting only endpoints/queries that you wrote yourself exposed in the api.

This is pretty cool tech--if the smart alarm system works as advertised it would replace a lot of poorly-performing manual processes I currently undergo myself. Make a version with no heating element that can run on a battery and I'll buy it.

Make a version that has active cooling and I'll buy 2 and wear the extra to work.

As a real full-stack engineer, I see more job postings for front-end than full-stack. And most of the full stack postings I see are for Ruby, which I don't have a lot of experience with, and Java, which I'd rather not do.

And JavaScript, of course. Usually these are titled "JavaScript Developer" but they really mean "CoffeeScript Developer" and no thanks.

All of the opinionating is really to say it only makes sense if it's what you want to do. I happen to like programming (including JavaScript) so I do back and front end. If you don't like JavaScript don't do front end because it can and will get complex, and JavaScript doesn't help you manage complexity.

That said, if your plan is to work on web applications, the more JavaScript you know, the more valuable you'll be (in theory) to your employer/client.

tl;dr maybe

I made a file tagging system with node-webkit and Vue (+ gulp/browserify/partialify). Vue was a joy to use. Most of the complexity in the app was dealing with sqlite, Sequelize and many-to-many relationships. Once the data got into a Vue VM it was smooth sailing.

I did run into some performance problems (rendering huge lists into complex tables), but I was able to iron them out for the most part. The only downside, which is definitely not unique to Vue, was debugging--a ton of functions get called in the Vue code when model data changes, so it can be tricky to find the right combination of breakpoints to set to track down why what you're expecting to happen isn't happening.