Use F# with a TypeProvider. Of course, I imagine it would take some work learning F# but once you learn it the sky is the limit in what you can do with this data.
Inbox wasn't a web app. That's why never used it. You had to install the app onto your phone. Since I'm a light user of email this didn't make sense. From reading the comments I can see why people loved it as a full app though.
Reminds me of F# type providers. Maybe more powerful? I think defining everything at the DB makes sense and then you can generate much of the code beyond that and then you only need to write the custom code that a programmer actually needs to do.
Pretty neat. I'm assuming you cache the results from the google sheet and update them when the google sheet is updated?
Another idea. Would be to have a "under maintenance" flag you could mark in the google sheet and then only the updates would happen on a secondary test site. When you are satisfied with the results you can change the flag to go live.
I find F#'s type inference to be really nice. You feel like you are almost writing in a scripting language but whenever you mess something up it will tell you. And if you say, "No F# you are wrong!" F# always wins. And the ability to write small pieces of the code in F# interactive is tremendously useful. I find I like T-SQL for that same reason. I can write small programs scripting as I go and bring everything together in a bigger program all without having to worry about types too much. The tooling isn't quite as nice with T-SQL as it is with F# (granted C# blows F# away with its tooling, but F# is catching up slowly).
What's nice about T-SQL is that you can do a lot of your programming in it and then you generators to generate all your C# code (Query-First) and even your client side code (I'm working on a console app that will do that for me). But the tooling for this is not very mature. I don't understand why programmers don't embrace it wholesale. I feel like I'm always writing so much cruft in my day-to-day job and screaming at the computer that I could do what takes an hour in C# in 5 minutes in SQL.
SQL is a bit harder to learn at first. But the more you work with it the easier it gets. And it is much easier to understand since there isn't much to it, unless you are doing something really complex. But then, I don't know if C# is that much clearer.
I just wish the tooling were as nice for PostgreSQL as it is for SQL Server. I don't understand how you can pay $200 for a product that can't even figure out what fields my alias refers to.
Apple is, by US law, required to maximize their profits for its investors.
I'm not religious, but I agree with the sentiment: "Thou shalt not covet." Rather than drag on Apple maybe we should be figuring out how everyone can lower their taxes.
Languages like F# give a nice sweet spot between static typing and dynamic typing. It has Type Providers that "generate" code on the fly as you are typing. You don't need to specify all the types, it will infer many types for you. So, you almost feel like you are writing in a dynamic language but you it tells you if you are writing something incorrectly.
I would not consider a language to be modern unless it has Type Providers I consider this to be such an essential feature. I believe Idris and F# are the only languages that have it. People are trying to push TypeScript to add it - who knows if it will happen.
Many are saying that if you have a dynamic language you just need to be disciplined and write many tests. With good static typed languages like F# you can't even write tests on certain business logic since the way you write your code you make "impossible states impossible", see https://www.youtube.com/watch?v=IcgmSRJHu_8
Many non-profits exist to make money too. Some people find doing a non-profit makes more money than a "for profit" company. I do think that money isn't always the main motivator, it's more complex than that. But generally, at the end of the day, money matters, even for non-profits.
PostgRest with Mithril.js or Elm on the front end. Keep it simple. Or WebSharper with SQL Server for a more integrated feel with static typing all the way from the database all the way down to the front end. Studies have shown static typing to be extremely important for removing bugs and programmer productivity, and from what I've seen WebSharper would give the best experience for that.
I've only used Mithril.js in those technologies though.
I built an app in Excel 5 years ago. It was a heat map for events, for stadiums, theaters, etc. I would build the static CSS/HTML and write out the files from Excel. It is still in use today. After having stopped working on it for a couple of years a minor bug was brought up to me recently. Luckily I had a windows computer again with Excel installed. Excel is a great platform for building prototype apps, or even long lived apps - especially 10 years ago. It is amazing the power that Excel has. But, a proper app should be built in JavaScript with a solid back end (F# being my fave). Although developing in Excel was a bit clunky it was amazingly easy to get beautiful customer interfaces and beautiful forms.
Something missing from this entire discussion is that developers have a hard time understanding what are truly best practices for their product they are creating/maintaining. It is a bold assertion to say that everyone understands all the different nuances in creating software.
The best ORM ever, F#'s FSharp.Data.SqlClient. A very thin layer that let's you statically program in SQL in your app. But I typically just use Functions/Stored Procs. But sometimes, for one off things and experimentation it can be nice to write SQL directly in your app.
F# is an amazing language on the .NET stack that is strongly/statically typed but will infer many of the types. It has TypeProviders which let you strongly type your external code sources (FSharp.Data.SqlClient is just amazing - statically typed SQL directly in your code!). Unions/Discriminated Unions, units, etc.