Closed JockLawrie closed 8 years ago
Thanks @JockLawrie - I've added AccessControl.jl to my list of cool packages I can use! I'm super happy every time I can use something already built as I'm still working alone on this and it's a lot to cover!
At this point I'm taking steps towards the MVP, which is the feature set for rapidly building high performance APIs. Hoping that this will generate enough enthusiasm and momentum to get more contributors to work towards the full stack part, full view layer (HTML and JS views, reactive UIs, etc).
In regards to APIs, 3 things come to mind, in relation to access control:
Are these things available or on the road map soon? I see rate limiting already, but I'm not sure if it can be used as a throttling mechanism for any request?
Cheers, Adrian
Any early benchmarks compared to say django?
Hi Adrian,
Regarding your questions:
config
object.tiered_members
example here.A few other thoughts:
examples
folder. Try running these to see how they behave. E.g., go to examples/authorization
and type julia tiered_members.jl
, then go to https://0.0.0.0:8000/home
in your browser.Cheers, Jock
...regarding benchmarks, no not at this stage. Currently I'm focusing on features, then security, then speed.
That said, I ran a simple hello world app i Julia and in Flask (Python) and Julia performed better. Not bad for no serious investment in performance optimization. This is a simple case however and doesn't reflect real world usage of course.
Just want to jump in and say that I'm looking forward to seeing how this package evolves! I'm running juliabloggers.com on WordPress, I've love to switch it over to be served by Julia as proof that the language is maturing
@datnamer No benchmarks yet. For now I'm focusing on features, for promoting developer happiness and productivity. I expect Julia itself, being compiled, will provide good enough performance. Also, I've been coding relatively carefully, linting often, using types, memoization, etc.
Once that's done, either a 0.x release or even the whole v1 will be all about performance. The usual suspects for refactoring: the persistence layer (there's a stack of Postgres.jl, DBI, DataFrames and my Model) and the view layer (json templates, Mustache templates, etc). Plus various layers of caching.
@randyzwitch I'm happy to hear it. Might take a while though, depending on how you want to approach it.
The issue is that a feature rich view layer is a huge undertaking - something that I don't feel I can solve on my own. Templates parsing and rendering, asset pipeline (minification, concatenation, versioning of assets) and caching are core. Then adding support for things like HAML, SCSS, etc.
My plan for v1 is to release it as a framework for building APIs with strong support for JSON and WebSockets (Channels). It will include JSON templates and some basic support for HTML via Mustache.jl templates. But the HTML part, I see it more as a tool for building small views for things like OAuth sign up / log in forms, which are usually provided by APIs.
On the way to v1 I'm planning on building a few projects with the framework - and for the front-end I'll go with Ember, most likely. Because Ember, with its Ember CLI provides an excellent view layer, with all the needed features and tooling. I'll document my experience and if you will want to go this way, it's definitely a good way to do it and I'd be happy to participate if you decide to build it as an open source project.
After reaching v1, if more contributors will join, a full view layer should be a priority.
Makes sense. What about Escher for the view layer? Its supposed to cover most or all of html, css etc
Yeah, could be a way to go about it. Though Escher seems to be a complete solution on its own. Some sort of MVVM architecture - if you add some DBI, one could whip up a CRUD scaffold. Sure, there's more to it; validation comes to mind, for example.
One of the things I'd like to do at some point is to extract the various components into separate packages - the ORM would be a first candidate for that. Then probably easier to drop that into an Escher app for easier CRUD and validations.
Separating out the ORM sounds like a good idea.
Have you seen this: https://github.com/shashi/Relational.jl
Also this: https://github.com/JuliaDB
Also there is some interesting stuff coming up like multithreading, traits (or protocols or some variation thereof), and perhaps compilation to web assembly. Might make sense to leave room in the design for these things.
Hi there,
Found this project by looking at the (few) stars of SecureSessions.jl. Thought you might be interested in AccessControl.jl.
It is very much a work-in-progress, just thought I'd mention it, particularly if it overlaps with your project. Feedback welcome, though I'm trying to keep it low-level at this stage to enable framework authors to wrap it with their preferred style.
Cheers, Jock