We'd set up a derived collection of "timesheets that need approval" and export that to an emailer system. Every time a new entry shows up in that collection the emailer will send out an email to the respective manager (whose email address would probably also be part of the data exposed to the emailer system).
So, in essence, you hook up a separate system to a part of the data (we have a system ready made for this particular use case), and the datastore will push all changes in that data to this system.
As a UX designer / dev I ensure you those concerns are front and center for us ;) The modeling language basically ensures applications are easy to understand, and we have lots of solutions to make them easy to use as well.
You’re not alone with that gut instinct. We haven’t run into that problem though. Also, that last 10% can probably be achieved using a custom side app, or a custom front end. We didnt cover that in detail in the introduction, but the options are there. Also, current traditional approaches aren’t guaranteed to get you near 100% either. They may hold the promise of getting there, but we’re usually dealing with clients who understand that most projects don’t make good on that promise.
Thanks for catching that. Did I mention we're still moving fast and breaking things? ... Sorry. The tutorial text should be fixed, will be looking into the Alan Connect app.
They have a head start in getting to the market. We need more time to reach their level of maturity, but we believe we have the core concept and technology to surpass them quite a bit. For the really large projects our focus on the core specification already makes a difference.
Because we continuously reuse use a fairly limited number of patterns we get to optimize the hell out of them. At a generic level, not specific implementations, but you can still make them fast.
There are some other mitigating factors, like:
- the datastore is fully in memory
- you can spin up multiple datastores to share the load
You also don't tend to accidentally run into a performance issue. The constructions that cost more (e.g. nested derived collections) or are risky (kicking of derivations at a high interval) are known beforehand. You tend to know already if you're going to use a lot of memory or expect high CPU load.
If prettiness isn’t a key selling point, doesn’t mean it’s not gorgeous. Sorry if it came across like it’s not a priority for us. But it’s not what sets it apart: all our competitors also have pretty apps, they don’t have our language.
Fair points. Honestly I think our default UI looks pretty rad and it’s super important to us.
I think we need to do a Show HN at a later date to showcase it. There is so much to say about the platform, we wanted to focus it on the modeling language right now. I totally understand people want to know more about the UI though.
I don’t know jasonette in detail, but you should think of Alan primarily as a way of building and iterating on apps with lots of guarantees about data quality and matching specs, not necessarily a way to build an app quickly.
The permission model actually only landed a few weeks ago, so we haven't been able to fully appreciate what we did ourselves. You're right though, it's probably a pretty huge deal :)
It definitely could. However, written language is really powerful. We're still developing new features for the modeling language and keeping the cost of each iteration down is super important for us. A visual editor is something that would definitely help empower our target audience, but right now it would get in the way. I would love building something like that some time in the future though.
Ah, like that. It's a fair point, but you're interpreting the model at too low a level. You don't have to model all possible values of scalar types (number, text) because the implementation of all possible values is known. I.e. you're writing a model that will drive the behavior of the application in terms of business rules, with specifications that matter to users of the application.
The line `password : . 'Password'` points at the password property, which tells the framework to hash it. What kind of hashing isn't something you should have to specify or worry about. It's a strong salted hash and we'd like to make it even better at some point, but that's firmly in the realm of the framework implementation.
Thanks for the feedback, this is exactly what we're looking for here. Perhaps some of this is "how to launch a platform 101", but we can't guess all the concerns everyone may have. Also, we're not necessarily looking to really kick start adoption for a wide audience right now. The platform lacks maturity on a number of levels to properly support that.
We'll continue to work on our documentation and clarify some of the things you mention here. A grab bag of quick responses:
The server is in-house, written in C and C++ and (at this moment) closed source.
We don't support custom functions, but we do support custom applications that run alongside the stack. They can be written in anything, and we have tools to quickly develop such systems in JS, TypeScript and C++. They're not part of what we're making available to community users right now, so documentation is still a bit limited.
We understand people want to see the UI, but it's not the key selling point. Pretty apps isn't what you'd use Alan for (although you could). We try to focus on the modeling language, as it's hopefully unique and cool enough to draw the right audience in.