Currently, I have decided to use Python and JavaScript (especially React and Node.js) for any of my projects. Well, I have used Python with Django for a lot of things, and I would certainly recommend Django to anyone, due to its high secure authentication and authorization inbuilt system, a ready to use admin platform, template tags, and many more. Well, I guess that you would like to use Python to create the backend of your application, an API, and React Native for the frontend. Python and JavaScript (React) are on the trend these days and have a huge community, so there are many resources, tutorials, great documentation. I have not really heard anyone using Flutter and Go for applications these days, so I would not recommend it to you, it would make your life much more difficult.

Hope that helps, and good luck with your project!

I'm typically agnostic when it comes to picking languages. Whatever gets the job done, but, in this case, to figure out what's involved with what you want to do, it's going to be much more than just picking programming languages for your client and backend interfaces.

So, I'm recommending you use Flutter+Firebase as a way to figure out what you need to get done. It supports both iOS and Android out of the box, introduces you to a bunch of components you will need to think about in the future (whether you stick with Firebase or not), and the key here, is that there are tons of articles, youtube videos, and other courses you can take to pick it up pretty quickly. You could even clone an Instagram knockoff from github. Guess what else, it's all free. You might not need to worry as much about the backend since there are client libraries for Flutter/Dart for Firebase.

Some might have different opinions, and like I said, I'm usually agnostic, but in this case, you have a lot to consider. Where are you going to store the data? Are people going to need to login? Will there but customized settings the will save even if I close the app? Yeah, that's just a few questions.

Those are just a few. Lots to consider, so if you want to get something in your hand as soon as possible, try a search for flutter + firebase + chat + Instagram or something like that and have a look.

If this is for learning about how to design the system, then pick the tools are you are confortable with.

Often times, I get stuck picking the tools (and trying to learn about them) vs actually trying to design the system itself.

If you are familiar with React (check out Expo) and Django then I would recommend going with that.

For deploying your backend, I would go with a provider like https://zeit.co/ that automates a whole bunch of deployment steps with their cli tools that you might have to do with AWS.

The above listed tools will do the job, you just need to figure out your architecture(e.g models). How they will all connect. Then you can use a tool you are comfortable with to implement them.

What you need to take a look at is Apache OpenMeetings. It already does what you want, it is open source and well documented and only requires that you design the UI and plumbing required to serve you application.

Let's select right tool you feel you are good at. And selecting tools are used by large community to solve your stuck if encounter

I've worked with all three of these languages and also with Java developers converting to these languages and far and away Go is the easier one to convert to. With the improved cold-start times and the ease of conversion for a Java developer, it is a no-brainer for me.

The hardest part of the conversion though is going to be the lack of traditional Classes so you have to be mindful of that, but Go Structs and interfaces tend to make up for what is lost there.

Full Disclosure: I'm a 95% Go convert (from Python) at this point in time.

Although I am primarily a Javascript developer myself, I used Go to build AWS lambda in a similar scenario to yours. AWS libraries felt better integrated on the Go side, I believe due to the language itself (e.g. how JSON objects are handled in go). Besides that performance of Go is much superior. But on the cons side; community is far smaller around Go, compared to Javascript. That is easy notice if you look at repos of community-maintained libraries for Go. That can feel a bit unreliable.

Go would provide the easiest transition for Java programmers -- its IDE/tooling is second to none (just install Goland) and the deploy/distribution story is extremely clean and lends itself to work well in lambda: single, static binaries with quick startup. No need to set up a full environment or package dependencies on your lambda AMIs, just copy a file.

If you want to prioritise language familiarity, JavaScript is more like Java than the other choices; and it can be optimised to run very fast. However if you need really fast cold-start times, you can't beat Go since it's compiled. There are other things to consider, such as the massive amount of community packages and help/documentation in the JavaScript ecosystem. Go is newer but seems to be quite popular if you need something that runs fast in a single binary.

I was initially going to suggest JavaScript due to the smaller size needs of AWS Lambdas code and the larger range of libraries and community available (and to avoid Python for this). But I have to agree with the recommendations and rationale of @ayildirim above and I think you should choose any reasonable language that is low-overhead, fast startup, and best supported by AWS Lambda, and that is probably Go. I don't think you are likely to go wrong with that, while you can potentially with the others.

So I'd agree, on the strength of AWS Lambda support and the solid performance of Go, it seems like your best choice here for Lambdas (and I'm going to need to consider that myself going forward... pardon the pun).

I've picked Node.js here but honestly it's a toss up between that and Go around this. It really depends on your background and skillset around "get something going fast" for one of these languages. Based on not knowing that I've suggested Node because it can be easier to prototype quickly and built right is performant enough. The scaffolding provided around Node.js services (Koa, Restify, NestJS) means you can get up and running pretty easily. It's important to note that the tooling surrounding this is good also, such as tracing, metrics et al (important when you're building production ready services).

You'll get more scalability and perf from go, but balancing them out I would say that you'll get pretty far with a well built Node.JS service (our entire site with over 1.5k requests/m scales easily and holds it's own with 4 pods in production.

Without knowing the scale you are building for and the systems you are using around it it's hard to say for certain this is the right route.