Advise on building a meeting app

Alright, to explain myself. I want to make a pretty simple app hosted on the web with the purpose of organizing events and building up a network for meeting various people around the world. I have the design for it figured somewhat, but I want some advise on what tech to use. ~Features -Federated servers -client agnostic (although official javascript client will be on the main site) ~Things I would like -make it as least time consuming to set up as possible. Preferably just shipping a compiled program you can easily run -as little dependencies as one can get Client I am already making with svelte in javascript, as it's pretty robust and quick to do. But the server troubles me. What I thought are combinations of these things ~Kotlin as language --plus -Easy and quick to develop in -Mature java libraries to use for serializing and databases --cons -Kinda annyoing to set up for other people because of jvm, going against the ease of use ~Rust as language --plus -Should be very low on resources -Can be shipped fully complied, without any vm on top --cons -database management is more complex than I would like -stability doesn't exist in many places I guess if someone wants to recommend more languages or tools to get around this, it would be appreciated. These are just ones I like to work with/know. General feedback welcomed too. Also, would it be wise to just neglect a database? I would really, really like this to be as simple to install as possible, and database already complicates things. Would be using a file to store data be a bad idea or no?

>Also, would it be wise to just neglect a database? I would really, really like this to be as simple to install as possible, and database already complicates things. Would be using a file to store data be a bad idea or no? It depends on how well you need it to scale. If you're expecting a low amount of stored data and updates to the database to be rare, then writing your own implementation where you write the database to file on updates and otherwise keep it loaded in memory may be fine. But if it needs to scale to some huge level, you might want to use an existing and more scalable database. You can always have an API for database operations that abstracts away the implementation details and supports depending on different database systems. Maybe start with a flat file approach and add support for other approaches later, if it becomes necessary. >languages Go has pretty comfy support for serializing/deserializing JSON objects, decent library support, and no VM. Do you have a spec? I've been thinking about writing a federated tracker for IRL events in rust or go for a while. I could contribute to yours, if you're open sourcing it.

>>32689 Consider building it on matrix or fedi (activityPub) since they already have users, servers and libraries. Consider using Elixir: >it’s a nice language >it support live updating (the user doesn’t need to stop the service to apply an update) >uses the actor model which can automatically recover from bugs and is highly scalable >it has an embedded database (Mnesia) >it can create self contained binaries with the VM, Mnesia, libraries, application code, html pages and JavaScript >phoenix is a http framework with features like push notifications and pubsub system >more stuff I don’t remember right now You probably should not use a text file. It’s hard to prescribe what database you should use because you didn’t specify how much data there will be. >SQLite Embedded. You can ship it inside a single binary. Small, fast and safe, the database is a single file that can be copied around. Won’t scale to big deployments specially if you need concurrent access. >Postgres The default database nowadays. Reasonably easy to install and configure on a any linux distro. Super performant, will scale to massive deployments (instagram uses it for example). >Mnesia Only works with Erlang and Elixir. Embedded in the BEAM VM and thus the user doesn’t need to configure anything. Key-Value based (SQLite and Postgres are relational, this doesn't matter as long as your data doesn’t have a ton of relations). I’m terms of concurrency it basically scales infinitely.

>>32689 >>32692 That has already been done IMHO. There is Mobilizon [1]. It is federated, fully open source [2] and it is written in Elixir (which I agree with). One of the instances (not the project page) is [3]. It is hosted by the developers, Framasoft. They are a pretty good community, focusing on liberating the internet and mayor platforms. They are mostly french, which explains why a lot of people don't know them, the pages are first in french then translated to english then translated to other languages. They are some of the people behind PeerTube [4]. Mobilizon is mostly present in Europe, but there is no reason why it couldn't be more well-known elsewhere. Maybe you can host an instance, maybe you can help with development, maybe bring more attention to the project. Maybe all of them :) [1] https://mobilizon.org/en/ [2] https://framagit.org/framasoft/mobilizon/ [3] https://mobilizon.fr/ [4] https://joinpeertube.org/

>>32697 I wish peertube was written in elixir.

OP here >>32697 That's a cool project, and it is close to what I want tech wise, but not design wise. Not to bash on the project, as I can see honest work went into it, but like most open source and federated projects do, it's made for tech people by tech people. You can see even on the main page. The main page should already show you what you can do and figure why it's useful by itself. Not give you an overview about how it's ethical alternative. Because to most people just don't live in the tech world so when they see words as "libre" they go "huh???". I want to build something inbetween your standard central app and a federated one. Having most of the ease of use and discoverability of the first, while running outside of the usual adveritsement spying networks like the second one do. And for that I need to go on my own because to do that with mobilizon I would need to change minds of many people to even get acceptence to try my ideas. I rather do the experiment on my own and see how good or bad it goes. >>32690 >Go has pretty comfy support for serializing/deserializing JSON objects, decent library support, and no VM. I actually tried go some time ago. I didn't really like the way it handled SQL. Maybe I didn't get something but the way you need to move data from a query into structs produced pretty long lines of code which I don't like. But I fully admit it might be from my ignorance. >>32690 >>32692 As for database. I think I'll go with sqllite. It's fast enough for what I want to do, and you can keep the code abstracted away from specific implementation if it turns out to be lacking in the future. So thanks for recommending all that. >>32690 >Do you have a spec? I've been thinking about writing a federated tracker for IRL events in rust or go for a while. I could contribute to yours, if you're open sourcing it. I'll try to get something out by next weekend. I'll then say the specifics since right now I'm still playing around with few design decisions on how to get build it and lot might change. I'm using rust with actix, as it's the most stable and mature framework so far I know. So that most likely won't change. But yeah, next week or so I'll show the code and everything. So till then

>>32703 >As for database. I think I'll go with sqllite. It's fast enough for what I want to do, and you can keep the code abstracted away from specific implementation if it turns out to be lacking in the future. So thanks for recommending all that. What do you mean? I assume you know about ORMs, right?

just use scuttlebutt, most of the functionality is already there, and you get all of your federation for free: https://handbook.scuttlebutt.nz/applications#infinite-game