mterrel

Also Adaptable.io and Render.

Adaptable.io has a free tier that includes managed serverless Postgres (or MongoDB).

Adaptable.io has a free tier and includes a database (Postgres or MongoDB).

Take a look at Adaptable.io. The free tier includes your database and supports MongoDB directly, so it's great for MERN apps.

If you're looking at alternatives, you might check out Adaptable.io. There's a free tier that includes the database.

Adaptable.io just launched managed Postgres, included in the free tier

Adaptable.io is definitely trying to make a better developer experience for startups and other devs. I think it's easier than Heroku.

Good to see a bit of pressure on some of the entry points that allow spoofed numbers into the phone network.

They are a great tool. We know a roofer that's using them to easily inspect and do initial quotes for roof repairs & replacements now...safer, easier, faster. Great idea.

Oh, and GitLab has put some AWESOME resources online about being a fully remote company. I've spent hours reading their employee handbook. Here's a place to get started: https://about.gitlab.com/company/culture/all-remote/

I don't think there's any one (or 10) things that magically make it happen, but all of these help:

- Meet in person as much as possible, especially by bringing remote folks together for an extended (multi-day) trip. That encourages more informal in-person interaction. Plan specifically for non-scheduled time, non-working meals, etc.

- Have a regular one-on-one meeting with your reports, preferably weekly. Set up the structure to always have a planned topic portion and some small talk about life. Sometimes that'll be boring or painful, especially for techies. But the space it provides is extremely important.

- Communicate

- Communicate

- Communicate

- Seriously, the one thing that erodes trust more than any other is when people feel out of the loop or not consulted when others were. Document hallway conversations for remote folks. This is hard.

Building strong trust is IMHO much harder remotely. That affects both manager/employee trust and trust among employees remote from each other. And without strong bonds of trust, certain things get much harder, such as negative feedback, even when delivered constructively.

Note that I'm not saying you can't build strong trust, just that it's harder. You have to devote considerably more thought and intentional time to it. I say intentional time because when you're local to someone, you naturally build trust with them in every small interaction. In a remote setting, you need to create time and space for those interactions deliberately.

In a small project, it's pretty easy for one or two devs to mentally keep track of the codebase and also makes any refactoring fairly quick.

As a project gets larger (more code or more devs), each dev spends more and more time figuring out what the correct types need to be when using various internal APIs. Refactors get harder because it becomes harder to know whether you've correctly found and changed each place that was needed.

And although all projects have this to a certain degree, one typical goal of a commercial project is a higher quality bar for software while still optimizing amount of effort to get that quality. (And commercial projects are often larger too.)

TypeScript helps with these issues (and others). In my opinion, it increases developer productivity for all but the smallest JavaScript projects. It's a combination of both the static typing and the tools available that help the dev immediately, as opposed to waiting for a compile or test run.

I'm actually passionate enough about the topic that I have an old blog article about it: https://medium.com/hackernoon/3-reasons-why-we-use-typescrip...

In my opinion, the power of the React/JSX model is really about allowing you to declaratively specify everything that can/should be specified that way. But then also allowing you to selectively use imperative constructs where they're needed, all while making it fairly seamless to move back and forth between the two at any level of abstraction.

Of course, with great power comes great responsibility...

My personal picks would be:

- React for the front end (https://reactjs.org)

- Node.js for your back end (https://nodejs.org)

- Deploy using Adapt, which ties your front and back end together using React-like components. (https://adaptjs.org).

- (Optional) If this project is larger or commercial, definitely use TypeScript on all 3 of the above (http://www.typescriptlang.org/)

[Disclosure: I'm a maintainer of Adapt, but a strong believer in the React model and ecosystem]

All sci-fi movies involving time travel are now ruined. Er..more ruined. Ruined-er?

I just wonder what happens to everyone's DNA data as the company faces financial trouble and/or sells itself. That's in addition to any concerns about possible security breaches that might occur.

I'm a big fan of Netlify for simple apps that don't have their own backend API, services, etc. They've done an awesome job of making things really easy.

Our vision with Adapt is to provide that same level of ease of use, but allow it to grow with your app. As your app grows and becomes more complex or as your app's needs change over time, it's easy for Adapt to handle those needs as well, in a way that's independent of any particular cloud or underlying infrastructure technology.