Hello everyone! Does this site still applicable un...

# server

[Ume Channel]

Hello everyone! Does this site still applicable until now? Or there's another solution for that connect the database that is a secure
https://idiallo.com/blog/dont-connect-directly-to-your-database

[Andrew]

Yes, that applies to any language you use to make a phone app or client application. If you don't put a server that you control between the app and the database, you're giving the user the ability to look at or delete other users' information. I think that the only exception is if you are serving a read-only database that only contains public information.

[Andrew O'Hara]

Many backend-as-a-service providers give the client application access to the database. Their method for security is to provide granular row-level permissions to each database user. So a user only ever has permission to access their own rows.

I can't speak for how scalable this is; nor have I tried it myself. 🤷

[Mike Dawson]

I have been working on an open-source Kotlin Symbol Processor (door) that can automatically generate an HTTP server endpoint and offline-first repository based on a Room database (multiplatform client currently supports Android, JS, and JVM).

On the server side: it supports JDBC SQLite and Postgres. SQL triggers / callback functions can be used to run security checks.

Instead of having to manually write an offline-first data layer with 5 extra classes, and then write server http endpoints, if the client is Kotlin, and the server is Kotlin, it can generate a KTOR server route with endpoints and an offline-first repository for JVM, JS, and Android.

I've outlined it here:
https://medium.com/@mike_21858/auto-generating-an-http-server-and-offline-first-data-layer-based-on-a-room-database-using-kotlin-a24f376db7ef

It's not ready for use in other apps just yet, but the proof-of-concept is working and it is being stabilized. Feedback / comments / questions on the API are welcome.

[hfhbd]

It really depends on your db architecture. With a proper security/user architecture it is okay to direct connect to your db, but properly, you would need to use procedures to limit/check the requests, eg invalid parameters.

[Mike Dawson]

I think REST endpoints that serve JSON are the defacto standard these days. Yes, with the proper security setup at a database level you could secure things.

REST still has various advantages: better tooling (e.g. KTOR client/server), easy to support on webapps (fetch json vs. trying to use an SQL dialect in Javascript), caching support, etc.