Thoughts on backends? about freespeech HOT 21 CLOSED

No not yet. I’m away from home but about to head home and I’ll compile a draft. But I’m also going add to the feature list features for the end user along with what should be expected as development standard. Things like ability to scale, caching, and security.

This is a community driven project and I want to hear what everyone has to say. Just in a more constructive organize manner. Please give me time to get a good place setup for that in issues.

from freespeech.

Alright, I gotcha!

Thought I would share a bit about my experience choosing frameworks for my organization. I run a student organization at the University of Alabama called Blueprint at UA that basically donates software development consulting to local nonprofits. We get students who have extremely limited time schedules, put them in groups, and set them up to build a project for a given nonprofit. The nonprofits we work with have limited budgets, have nearly no technical teams (so devops is out of the question), and want something as quickly as possible. Likewise, the students we work with have limited schedules, are usually beginners to web development, and use a variety of devices and OSes to do their programming. What we do at Blueprint is basically the same thing we're trying to do here: choose a framework that maximizes developer productivity while at the same time minimizing hosting costs and manual maintenance. Here's our criteria we've used for choosing frameworks in the past:

1. Consider limiting factors. First we start by considering limiting factors. If the nonprofit works with Wordpress, for instance, our solution has to be built to work with WordPress. If they don't want to pay for hosting, then we have to choose a framework that can deploy on Azure or AWS because both of those have grants for nonprofits that are good enough for scale.
2. Consider developer productivity. This covers everything from how much the framework does for you to how expressive the language behind it is. This also covers how easy the language and the framework are to learn, which is a blocking factor that keeps out a lot of our students (same would go for our contributors). Editor support, StackOverflow answers, and other factors are considered here as well. We want our developers to feel empowered when they're working on a project for a nonprofit, not like the framework is getting in the way.
3. Consider the development environment. A lot of our developers work on Windows, while some work on macOS and Linux. We want to make sure that the project can easily be set up for all of them. A lot of tooling is built to work well on macOS and Linux but doesn't set up as well or is much slower on Windows, so a lot of our work is focused on optimizing for Windows. There are some languages and frameworks that just don't work well on Windows: Ruby, for instance, (as much as I absolutely love it) is one of them. It's slow and painful to use, hard to install, and just doesn't feel good unless you're in WSL 2, which isn't GA and doesn't have great editor support. Tooling like Docker, Vagrant, some virtual machines, and usually almost all languages and frameworks that aren't based on Node fall into this trap and are almost always slow to use or just broken on Windows. People shouldn't have to dual boot into Linux to contribute to our projects.
4. Consider what our developers know. This usually falls last for us for a couple of reasons. First, developers know tooling that just doesn't fit the above categories, making it harder for other members to contribute to projects if that tooling were used. Second, the languages and frameworks they know don't always follow best practices or have a rigid structure that we need for our students to have. Developers, especially newer ones that we target, make mistakes. So, we want to choose a language and a framework where it is harder for them to make those mistakes.

So yeah. I think a lot of this would be applicable here, so lemme know what you think.

from freespeech.

For backend, there are a good bit of options for it. Firebase has some great options too for auth and storage. I don't think a custom solution would be needed, to be honest.

from freespeech.

I think we're going go around in a circle debating the best backend framework to use. I mean here is Stack overflows survey from last year. I think it's really going boil down to what most current contributors feel comfortable with. We can spend the rest of our lives probably debating which one to go with on merits and what one has and what one lacks. I think for now it'll be best we outline in detail what we would want out of a backend service, then go from there.

from freespeech.

To be completely fair here’s quite a few backends that meet all of your specifications:

• Rails
• FeathersJS (heard a LOT of good things about this one)
• Meteor
• GraphCool with GraphQL
• VulcanJS (really great GraphQL framework built on top of Meteor)
• AdonisJS
• SailsJS
• Parse Server
• PaaS backends that would probably give us discounts

There are a lot of options and just blanket-ly saying “let’s use Laravel” doesn’t give us the option to explore all of those. There are tons of frameworks like Laravel that do things basically the same as it; it is not unique. Security should be a concern, but right now for the type of data we’re wanting to store (literally just lists of words), so long as we’re not storing sensitive user information and use OAuth for login we’d be safe.

_{Sent with GitHawk}

from freespeech.

These are all excellent criteria

_{Sent with GitHawk}

from freespeech.

The main thing that I can see a backend being used for is syncing user preferences between devices. But I think user auth and syncing can be done in a more lightweight way than using a backend, and might be far enough down the roadmap to not stress about in the near future

from freespeech.

from freespeech.

I'm all for Firebase then. Has anyone had experience with it and know roughly some costs? I would like us to stick as close to free as we can. I know that's not always possible. But at least till we get the ball rolling some more and get some more donations flowing.

Another thing I'd like to see in the backend is a "Keyboard store" Where people can share their custom keyboards and people can download them. I said store, but all keyboards would be free of course. I think this would really get the ball rolling on people using it and sharing what works best for them in hops other can use them. Can even have ratings, times installed, and so on.

from freespeech.

I've plenty of experience with backend development and can easily write up a backend in Laravel if cost is seriously a concern.

from freespeech.

All for Firebase, the only thing I worry about is doing local development. Local development doesn't work offline and you'd have to have your own API key, which might be a larger barrier of entry for some developers.

from freespeech.

I think we could still use some more discussion and research on best way to do a backend. I think Laravel would be a great backend choice. Laravel treats Vue as a first class citizen and they work together very well.

What i would like to see in a backend is

• Low entry for developers and contributions. I really like the community we are building here. I want to make sure who ever wants to contribute can. W e want to give them a welcoming environment to learn and grow as developers. This also includes easy setup of development environment.
• Low costs and ability to scale if we get more traffic. Do not want to be caught with us not being able not to scale up and not be able to handle the traffic.
• A solution that is standard and used across the board.

from freespeech.

Well, like I said, I've had a lot of experience with Laravel over years. Just view some of my work in Halfpetal if you're curious. The app and the backend should be completely separate for this in my opinion. @fatfingers23 if you wanna join on Discord, #56, I have a couple ideas for organization of the project that you and @Merkie may be interested in and I can definitely help execute it as well.

As for the checkboxes:

• Having a non-firebase solution will definitely help some developers who are not used to that environment get setup and rolling. So a PHP, NodeJS, or Go backend would be a good solution. Laravel is pretty easy to grasp and I think it would be a good solution and setting up a backend would be pretty easy for it. As for user auth, it wouldn't be hard to implement a JWT token based solution.

• I've ran a Laravel application for 300m API queries for under $10 a month. Even though that wouldn't be enough in our case, there's definitely things we can do to keep it under $50 a month at most. Scale wise? It's very easy with Envoyer and Forge to launch and deploy multiple server and use Cloudflare to loadbalance.

• Well, that can be determined.

This can also give us more options for the website itself and have a bit more freedom there.

from freespeech.

Is PHP a good choice for being low entry for contributions? Should we go with something more modern/trendy like node?

from freespeech.

I mean...
https://github.com/topics/framework

VueJS then Laravel...I'd say that's "trendy"

Plus secure, widely recognized and accepted too. Enterprise ready and scalable as hell.

from freespeech.

Yeah if you pick the right topic you can argue either side https://github.com/topics/server

I mean more that we’re already using JavaScript on the front end. Using it on the backend means that you only need to know one language, the most popular language, to be able to contribute.

from freespeech.

@fatfingers23 I think it deserves more discussion than that. It seems we're boiling it down much simpler than what people are making it. Top thing should ALWAYS be security. Thing about the data we're handling here. This is sensitive information about people who have disabilities and store personal information related to that. First and foremost you NEED to consider that a top priority and the fact that most frameworks like Express you need to add packages like helmet just to ensure that XSS attacks are filtered out, among other things is a red flag for me. If there was a team dedicated to developing and securing that project it could work, but considering there's not...we need to have a solution that works and is secure out of the box that creating a MVP from wouldn't take more than a few hours to get up in running for integration with the app itself. In my experience, I truly believe Laravel is going to be the best bet there. With it's security out of the box, it's ability to integrate auth with one command, it's ability to switch between JWT and standard OAuth with ease, and the whole MVC style like RoR. I just don't think, for the purposes here, we'll beat it. If you can show me a system that you can get setup and running a prototype web server with JWT or OAuth based auth for a SPA, that's both secure from all sorts of XSS attacks among all the other attacks and can be deployed to 2+ servers without any issues whatsoever...I'll will gladly admit defeat in this situation.

But considering the type of data we're messing with here, and the fact that it needs to be secure out of the box, along with ease of learning, and easy to create and deploy features....I think Laravel will be our best choice.

from freespeech.

Sorry trying to figure out a GitHub client on my phone :/

_{Sent with GitHawk}

from freespeech.

I mean Donet Core. It is even strongly typed. There's Django that also comes to mind. All kinds of web frameworks that do exactly what you stated.

Also this is going get more discussion and of course security will be foremost! We're not tabling it, but i think if we outline what we need and go from there it will be easier. You outline some great things that i would imagine be in what we need out of backend service list. I was stating that we were going go around in a circle like we are now showing the merits of one vs another. Lets compile a list of what we want out of a backend and go from there. I think that will be much more productive and yield more fruit.

Lets mentally and to ourselves start compiling what we want, think the project needs out of a backend service. I'll make an issue that everyone can outline their opinions . Read what everyone has to say and make a decision then based off of that. Maybe even take it to a vote. I think once this list is compiled it will make it easier to decide.
One important thing to me is i do not want the backend to end up just being something one person is comfortable with. Talk about a security concern.

and for the record Laravel would be a great choice and is not out of the running by a long shot. I think it is a wonderful platform and i love Larvael! But saying its the only one that can solve our problem is just not true or productive to our project.

from freespeech.

Do we have a full feature list of what we want from our backend?

_{Sent with GitHawk}

from freespeech.

I've open #71 and #72 for further discussion. Locking this and closing it. Thank you again everyone for your support and willingness to work towards this common goal.

from freespeech.