> What I would like to see more of is “no backend” type solutions that allow you to just write front ends that leverage existing auth, databases, etc
I did the opposite of that, since I see the data structures are the "real" thing and the layout of the web pages as merely froth on the top.
My Frambozen[1] framework is all backend, in that you define your database schema, and then it builds parts or all of the front end (the web pages) for you. (It's written in Python and uses the MongoDB database).
So for example, you might define a table like this:
class Foo(MonDoc):
name = StrField()
description = TextAreaField(monospaced=True)
aNumber = IntField(minValue=0, maxValue=100)
minSpeed = FloatField(title="Minimum Speed, mph", minValue=0.0)
maxSpeed = FloatField(title="Maximim Speed, mph", minValue=0.0)
favouriteDrink = ChoiceField(choices=DRINK_CHOICES,
showNull=True, allowNull=True)
fruitsLiked = MultiChoiceField(choices=FRUIT_CHOICES,
desc="tick all fruits this person likes")
tickyBox = BoolField()
aDate = DateField()
lastSaved = DateTimeField(desc="when this foo was last saved",
readOnly=True)
aDateTime = DateTimeField(title="A Date and Time")
anything = ObjectField(desc="can contain anything",
default=["any", "thing"])
favouriteBook = FK(models.Book, allowNull=True, showNull=True)
And then it can auto-generate a page to view / edit / create a single record in the table, and another page to listr all the records in the table.
your pseudocode there mixes DB fields with UI components. On the one hand, you have a FK field and, on the other, a TextAreaField with monospaced set to True. Is this a description of a table or a view...?
> On the one hand, you have a FK field and, on the other, a TextAreaField with monospaced set to True. Is this a description of a table or a view...?
Both!
TextAreaField and StrField both define a string field in the database. The only difference between them is how they would appear rendered in HTML.
In the code snippet I included, MonDoc is a Python class that encodes the schema for a MongoDB table (MongoDB calls them collections). But MonDoc is actually a subclass of another class, FormDoc, that encodes data for an HTML form.
Using FormDoc, you can define the fields of your form, render it into HTML, validate results, etc.
The reason I merged forms and table schemas into one concept was I've used so many systems that define forms, and so many systems that define tables and they're all very similar, and I don't like having to do cut-and-paste to transform a form definition into an almost-the-same table definition. I find it tedious and error prone.
Does this reduce flexibility? It does a bit, by tying together forms and tables. But I think any rapid prototyping system is going to trade flexibility for speed of programming.
Ah gotcha, thanks for the clarification. I think the camelCase threw me off and made me think this was pseudocode (Python is usually written in snake_case).
I did the opposite of that, since I see the data structures are the "real" thing and the layout of the web pages as merely froth on the top.
My Frambozen[1] framework is all backend, in that you define your database schema, and then it builds parts or all of the front end (the web pages) for you. (It's written in Python and uses the MongoDB database).
So for example, you might define a table like this:
And then it can auto-generate a page to view / edit / create a single record in the table, and another page to listr all the records in the table.1: https://github.com/cabalamat/frambozenapp