1. 22

I need to choose something for a project and I am struggling with all of the choices - I don’t have much experience here besides a few small Rails and Flask projects. I am biased towards boring and battle proven but if something novel has a lot of support I am fine learning that too. It would need to support secure websockets and have decent concurrency (think a game).

  1.  

  2. 53

    A few suggestions:

    • Unless the purpose is to learn a new language, pick one you know well.
    • Twitter got to 10 million users on rails; unless you’re confident this is going to be huge, I wouldn’t rule out slower languages (within reason).
    1. 9

      I also think Rails or Flask in this case would be a great fit, as the OP mentions it explicitly. If you can do your job in a day or two, do it in Rails, move on, don’t make things up along the way.

      1. 3

        Agreed. GitHub and Shopify did ok with Rails too.

      2. 16

        IMHO, I think it is much more important to think deep about your data shape and data access patterns, rather than your framework.

        Most framework are quite nice, and we live in times where deployments are very similar. Find a cloud provider you like, and set up a github action or one of the other many CI/CD pipelines options. That will give you a ton of flexibility on deployment and allow you to change as you want. Also a very large part of the complex database/streaming offerings are reasonably easy to deploy or find managed at reasonable prices. (from redis to kafka). So my recommendation will be to think HARD about what you want to build first. And if you need Authentication and authorization go straight for managed services, or projects like https://casbin.org.

        That said, personally, I like “micro” frameworks. Flask (py) and express (nodejs) over all others. Or in other languages spring boot (java), sinatra, cake php, or mojolicious (perl). I like flask and express because they work great with lambda. and with docker. And with FAAS. And whatever else. The important part is that they don’t force me into deep enterprisey abstractions or ORMs.

        1. 6

          IMHO, I think it is much more important to think deep about your data shape and data access patterns, rather than your framework.

          Couldn’t agree more. Whatever your storage type may be, dragons sit at this layer that scuff/kill apps. What seemed like a tight and cohesive schema becomes hard to maintain for some, but not limited to

          -) requirement changes => schema migrations; can paint yourself into a corner SQL/document/et. al. they have their tradeoffs

          -) scaling limitations in the real world on the servers you’re using. That white paper may say however-many-million rows is fine, but is it that true for your setup?

          -) unexpected occurring “this mongodb reindexing is taking 24hrs! we thought it would be 1!” /everything breaking from external-to-you changes; like ObjectRocket moving from v2 to v3 broke things that “shouldn’t” break once for me but subtle changes were necessary to get running again

          -) Expecting the unexpected. As @bigdeddu very wisely suggested, have a Cloud/CI structure up front. Hard challenges can be solved if these are set as part of your arsenal

        2. 8

          If what you know is “boring and battle proven”, consider yourself lucky, because you have all the tools you need in order to worry about solving real problems within your domain.

          1. 7

            Backend doesn’t matter. Because if it has coherence problems with your problem domain, you will discover this and this discovery is where 90% of your learning will come from. So much, that if you find a framework that completes your domain’s sentences, you will know it, love at first site.

            What is your domain? How is your app going to be delivered? Who is the audience? Sounds like you want a game with realtime component. Search for 5 of these pick 1 to run a 3 day experiment on, run the experiment on the remaining 4, giving yourself 1 day each. You don’t need advice, you need meta-advice. Unsolicited.

            1. 2

              Backend doesn’t matter until you need to scale. Frontend doesn’t matter until you need to scale.

              I’m developing a project right now and am stalled on the frontend. It’s a CRUD webapp and I’m driving it with 2 shell-scripts that wrap curl. It still takes 1 second per POST-request to change stuff. I need to make a lot of requests until I clocked up enough hours to have better written the frontend ;)

            2. 6

              My apologies if this is a bad question but I don’t know where else to ask it - I respect the opinion of the users on here a lot.

              1. 5

                To be honest, I’d choose Go, C# ASP.net MVC or Node.js. Node.js would probably be the easiest to start with, but any tricky numeric logic would be better served in Go or C#.

                It really depends on the project, but those three languages stand out in my head for not being crazy hard to learn and having decent websocket support.

                Elixir also has a strong support for websockets and concurrency, but it’s can be a bit to learn.

                1. 5

                  What about learning Elixir is difficult? Understanding BEAM? I was considering Phoenix

                  1. 7

                    I am currently learning Erlang (properly this time around) for fun, intend to dig into Elixir and Phoenix after that.

                    I don’t think you need to know Erlang or BEAM internals to start with Elixir. I think the parent might be referring to the scope of the ecosystem - there is a lot you can learn like OTP, distributed computing, fault tolerance. If you want to start from Erlang I went with Joe Armstrongs thesis and now following up with Learn you some Erlang.

                    I had past Rails experience and Phoenix seems very easy to jump into from the rails perspective, it’s also pretty impressive. Just a few days ago I stumbled on this video which shows how to build a real-time twitter clone in 15 minutes. If you have rails background you probably seen a very similar video for rails about building a blog. Give it a try and see if that’s what you are looking for in a framework.

                    Erlang and Elixir both have been heavily used in the gaming industry. For example the Call of Duty backends use(d?) it, Discord is also using it. I found a similar slide showing off Elixir for a game backend but can’t locate it atm.

                    It would need to support secure websockets and have decent concurrency (think a game).

                    It does seem to perfectly fit for what you want to build, of course that is assumed after the quote above. It might be perfect or completely unacceptable based on what exactly you want to do.

                    1. 4

                      Elixir on its own isn’t too bad. I’ve tried to learn Phoenix a couple times for side projects. At least for me, learning Phoenix will have to be a project unto itself. Not that it’s crazy, there are just enough moving parts a default Phoenix application exposes at once that I feel the need understand that it gets a bit overwhelming for a small project.

                      There’s also the fact that Elixir is functional and immutable, which can be an adjustment as well.

                      If you’re familiar with Rails, Phoenix might be easier to understand, but I don’t have that background.

                      That being said, if it’s highly interesting to you, it’s not a crazy amount to learn.

                  2. 5

                    I would pick the most stable framework in a language you enjoy using.

                    Performance is an issue that you would be happy to have later.

                    1. 4

                      As always: it depends.

                      What is the goal here? For example, do you want to learn a new language/framework, or do you want to get something functional to market fast, so you can test the market? Or something else perhaps?

                      If the goal is to get something out to market ASAP – use something you’re comfortable with.

                      If the goal is to learn (which is great!) – check out either Go or Elixir, I find them both worth learning.

                      What I would suggest is avoiding mixing up these two (I’ve done it a few times in the past). Building a product while learning a tech stack will be frustrating, and most likely you won’t be happy with the result (which is to be expected, because it’s your first project in $NEW_STACK).

                      Have fun building!

                      1. 3

                        Personally I prefer node and express. It’s “old” now because everyone is rewriting in rust or something now, but node/express has worked since 2010 and doesn’t show any signs of stopping. Node also has good websocket support.

                        Node generally scales… okay. You have to use multiple instances once you need to scale higher. Go has better concurrency but has less of an ecosystem. There’s also Python and Flask if you like Python. Or maybe Laravel if you like PHP.

                        1. 3

                          Depends on the project. If there are good libraries for what you’re doing in some language, or you’re happy with the language, I’d pick something there. I’d aim for something minimal, likely either Bottle, possibly Flask, and maybe Go’s standard HTTP stuff without a framework. I don’t think it’s a particularly important choice, as long as you’re comfortable with it.

                          I may also consider well-sandboxed CGI (or Lambda, it’s roughly equivalent) scripts in a compiled language, depending on the project.

                          1. 3

                            I am biased towards boring and battle proven but if something novel has a lot of support I am fine learning that too. It would need to support secure websockets and have decent concurrency (think a game).

                            You have some Python knowledge and you need websockets. Maybe the async-based aiohttp framework, then?

                            1. 3

                              Can you get away with just using firebase? It has serverless functions and push.

                              1. 3

                                If you’re opening to learning, I recommend checking out Clojure. It’s concise, fast, has a great concurrency story, facilitates interactive development, and you can use ClojureScript on the front-end, so you have the same language and tooling for the whole stack. Here’s a run through of building a small app, and a talk that shows the workflow.

                                1. 2

                                  I bought your book a long time ago but I never got the hang of Clojure, it was a lot to try to both learn the framework and the language at the same time. I like Lisp and if this were a pure learning thing I would consider it.

                                2. 2

                                  OpenResty looks like fun. http://openresty.org/en/

                                  Or maybe wt. https://www.webtoolkit.eu/wt

                                  1. 2

                                    I am happy with Javalin https://javalin.io/ [1] Modern Java (or Kotlin), relies on Jetty.

                                    It is not easy to define ‘criteria’ by which to choose something. So will share what we had:

                                    • Overall the criteria were to reduce different programming languages to a minimum’ between fronts and backend.

                                    • Leverage async io.

                                    • Minimize the number of ‘tools’ to deploy in production (eg web servers, cache proxies, etc) by using a framework that relies on a competent web server.

                                    • Additionally, our whole backend should be releasable and deployable as a single file (eg Jar), running different services on different port. Optionally, our installers could run same jar on separate JVMs/hosts by enabling/desabling features in single config file.
                                      Basically one jar, one config file, on database server – is all that one needs to run a fully functional backend.

                                    more detailed criteria that were of interest were:

                                    • must be able to selectively support async io
                                    • must be able to leverage Java 8+ jvm
                                    • I do not like annotations, so no spring-boot or such
                                    • must rely on proven web server so that I can, if I want to, use it as a web server facing public internet (so must support full spec http2)
                                    • do not want ‘big’ framework with nuts and bolts. do not want ‘database wrappers/ORMs’, etc
                                    • want light, yet flexible support for templating language of my choice (eg Pebble [2] )
                                    • need to be java or Kotlin so that our ‘internal SDK’ can be shared APIs with Android apps (the SDK mostly is a collection of classes describing rest APIs, as well as a bunch of utility functions )

                                    In my case corporate compliance with enterprise standards or other similar factors were not in play, but that may be in play for you.

                                    [1] https://javalin.io/ [2] https://pebbletemplates.io/

                                    1. 2

                                      If you’re familiar with Flask but want websockets I’d highly recommend FastAPI. I have a project that started off with Flask, but I really wanted a websocket for one silly, stupid thing. I wound up using it an excuse to learn FastAPI, and by extension Python’s asyncio ecosystem. FastAPI has been a joy to work with, the community is incredibly friendly and helpful and the documentation is great.

                                      1. 1

                                        If you want websockets and you’re coming from Flask, use Quart instead. It is literally Flask but rewritten from scratch, supporting asyncio.

                                        FastAPI is geared towards developing a REST API (which it is absolutely great at).

                                        1. 1

                                          I see - so it would depend on if you want to use server side rendering or not?

                                          1. 1

                                            Yeah, pretty much.

                                        2. 1

                                          I was considering using FastAPI but I was worried about how new it is. Have you ran into any hurdles?

                                          1. 1

                                            None at all, I’ve found the FastAPI documents to be a lot easier to understand than Flask, but I think a lot of that may have been from increased domain knowledge by the time I got around to working with FastAPI.

                                        3. 2

                                          A bit different to more traditional frameworks but with Hasura you get ready to use GraphQL APIs from a Postgres database. You can model data changes as async operations with events that run as webhooks and you can connect to existing backends through custom queries and mutations or remote schemas through schema stitching. It also has an ACL that helps you model the permissions which is super handy.

                                          1. 1

                                            Ha! I just stumbled into hasura today. It’s right at the top of my list of things to tinker with soon. How has your experience been with it? I’ve been in love with the power of the abstraction of aws AppSync, how do the two compare? I can’t wait to dig into those more.

                                            1. 1

                                              Absolutely love it. We’ve built a few products with it already https://medium.com/viewstools/build-with-views-613cd24633c0?source=collection_home---4------2-----------------------.

                                              The way it helps you architect your app is very powerful and simple. Events and actions make it easy to structure your custom logic that doesn’t fit in postgres.

                                              Haven’t used AppSync but from what I’ve seen it shares similarities in that it lets you extend a graph with custom behaviour. Did you manage to try hasura already?

                                          2. 2

                                            If it were me, I’d choose Node/Express and use Socket.IO for the websocket stuff. I have experience with both of them. If you’re not looking to learn a new language/framework at this point, I would just stick with Rails or Flask. They’re both fine.

                                            1. 2

                                              For something serious that I would start from scratch with no constraints, I would pick Flask. I have used it professionally almost 10 years, I know it very well, and it does everything I want. It is also well-known enough that I know I can hire people to work with it easily.

                                              Currently I use Rails at work, but I really don’t like parts of it, most importantly Active Record, so I’d avoid it.

                                              For small personal projects I might go with Lua because it’s the language I prefer, either through CGI or with Xavante. I like Lapis as a framework but I would avoid it because I like my Lua 5.3 features, and OpenResty runs LuaJit which doesn’t have them.

                                              1. 2

                                                I would strongly consider using CGI. Proven, mature, and flexible web technology that is hopelessly unfashionable but still runs everywhere. You can use any programming language you want and use different languages for different things. I’ve been having fun lately writing network-transparent utility programs that can serve as something like personal APIs. Many webservers support CGI with little to no configuration, and if CGI performs poorly you can upgrade to FastCGI or refactor the app using a more modern framework if experience proves you require it. In other words, I would assume I do not need a framework until my requirements proved otherwise.

                                                This example makes correctly formatted RFC3339 timestamps:

                                                #!/bin/sh
                                                # Unites RFC3339, RFC3875, RFC8536, and IEEE 1003 (POSIX).
                                                # An available TZDATA timezone database makes this program much more useful:
                                                # allowing for input like "America/Los_Angeles" instead of "PST8PDT".
                                                #
                                                # Do we have command line or GET arguments?
                                                if test -z "$1"
                                                  then TZ='UTC'
                                                elif test "$QUERY_STRING" != ''
                                                then
                                                  TZ="$QUERY_STRING"
                                                else TZ="$1"
                                                fi
                                                # Are we running CGI?
                                                if test "$GATEWAY_INTERFACE"
                                                then
                                                 echo "content-type: text/plain"
                                                 echo ""
                                                fi
                                                
                                                # The sed command corrects timezone offset formatting.
                                                echo "$(TZ=$1 date '+%Y-%m-%dT%H:%M:%S%z' | sed 's@^.\{22\}@&:@')"
                                                
                                                1. 2

                                                  Whether you use CGI or not is independent of the framework. For example, all Python web frameworks support WSGI. And WSGI can be plugged into CGI (in fact that’s pretty much how it was designed).

                                                  So all Python frameworks support CGI, so you’re still left with a choice …

                                                  1. 1

                                                    Fair, I suppose I should have clarified that I have been recently trimming down to just a web-server + CGI

                                                2. 1

                                                  By far, I prioritize developer UX. Minimize developer suffering; maximize developer happiness. To that end, my current stack preferences are:

                                                  • REST in the back (probably Grape (Ruby), but I could tolerate JS-based, like Express)
                                                  • Vue in the front, without a doubt
                                                    • including Vuex
                                                  1. 1

                                                    I’m trying to decide between react and vue for a side project. I’m more familiar with react so leaning towards that.

                                                    Could you provide some info on what makes vue your choice? I’d just like to make a more informed decision so I’m trying to learn more about vue

                                                    1. 2

                                                      I’m at the point in my career where my primary criterion for choosing tools and tech is minimizing [developer] suffering. Pain, frustration, annoyance, irritation, etc. Out of the major JS frontend frameworks, Vue gives me the least suffering. I just want as direct a path as possible from conceived thought to functional code that realizes it. Vue comes closest to that ideal path.

                                                      I’ve dabbled a bit in React – though not enough for me to make a fully fair and balanced comparison. React alone doesn’t seem to have enough “batteries included”. Vue has batteries included, but not too many batteries. Angular makes me want to stop being a full stack developer – but I’m willing to admit that perhaps it’s just the codebase(s) I’ve been subjected to that gives me that jaded view.

                                                      I’ll say this: The same awe and wonderment I felt from discovering the joy of Ruby I feel from discovering and using Vue. No other two technologies have given me that over the course of my entire career. The keyword list you could extract out of my resume makes a tag cloud as big as the next person’s. For all the other keywords in that list: I use them because I’ve had to (inherited codebase; departmental mandate; whatever). I use Ruby and Vue because I want to.

                                                      I realize what I’m writing here is somewhat anecdotal, intangible and immeasurable. So I propose this: Call to mind just how much frustration and angst you’ve felt when dealing with the tech in your current work. Hold that as a standard to compare against. Then go try Vue on a side project [of sufficient size so the results can’t be dismissed]. I’m pretty sure most people would find using Vue a superior experience.

                                                  2. 1

                                                    If you’re looking for boring and battle proven, I would suggest one of these languages: Java, C#, PHP, Python, Ruby, Go, Node.js or Erlang. I’ve had a hard time with web frameworks that aren’t in those languages. It’s not that I don’t understand them, just that I wasn’t as productive.

                                                    1. 1

                                                      Go Lang is great for concurrency, IMHO. Rust might be better but it is still somewhat unstable.

                                                      1. 1

                                                        Learning as you go can be fun, but if your priority is actually finishing this project whatever you’re most comfy with would be my vote. Do some Elixir tutorials when you start to get burned on this project a bit. You will get the satisfaction and dopamine of learning new fun things while you’re on the harder parts non-fun of your project.

                                                        When you get to parts you don’t like even though you need to complete them it will affect your momentum. A project you were psyched about is now a chore. Like getting SSL to work properly and make sure your authentication is rock-solid. Rails will have a glut of information due to community size. There are really good communities otherwise but the numbers are to your advantage picking Rails.

                                                        I’ve made this mistake before. The learning part can mislead you into feeling you’re making progress on this project. Then when things are going really rough and you’re not sure you’re learning the right thing to solve your problem anxiety compounds, projects are abandoned.

                                                        1. 1

                                                          Having worked with it for the past eight years I know Laravel inside-out and so would largely work with that as I can flow with the framework and utilise its tooling to accelerate an MVPs time to market.

                                                          I have used Express.Js in node and the standard library in Go (because its good enough to not need a framework on-top) but am not as quick to develop something usable as I am in Laravel.

                                                          If you were to choose a backend web framework today, what would you choose?

                                                          For me personally it would be Laravel, unless I was wanting to learn something new. Laravel is built on a solid foundation, constantly updated and with a large community from which to source help.

                                                          However I am a PHP developer and Laravel operates on a level I fully understand. Therefore the actual answer to your question is: “A framework that is battle tested, with regular, continual development, that has an active community and is written in a programming language you understand.” A framework is a tool kit, it should be a catalyst for developing good code quickly; boring is good.

                                                          1. 1

                                                            Go with what you know. I had played with Flask, Django and Rails in the beginning of my programming journey, but didn’t grok them. Probably because I didn’t have any foundational programming knowledge. Then I mostly wrote scripts in Python for 5 years.

                                                            Now I’m learning and deploying an enterprise app in Django and it’s (close to) a breeze. Django is highly battle tested, has DRF for building (albeit somewhat constrained) APIs. And in general let’s you worry about data shape and data access patterns rather than the nitty gritty.

                                                            So. Go with what you know.

                                                            1. 1

                                                              What is the current sentiment on using a Rust-based web framework? I see it hasn’t made it into anyone’s answer yet.

                                                              1. 2

                                                                I don’t think it’s practical to use non-gc aot “systems” language for most web projects. Additional overhead to manage memory, problems with stacktraces, slow compilation times.

                                                                (There are lots of valid uses for http servers in Rust, however; for example, web interfaces embedded in applications or http-based protocols for networked services. Just not standard “database-backed massive user-facing thing with lots of html templates”).

                                                                1. 1

                                                                  I can’t think of any reason I’d want to write a web application in Rust, and I’m pro-rust.