FYI - AccessControl.jl

[genieframework]

FYI - AccessControl.jl

[JockLawrie]

...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.

[essenciary]

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:

1. token based authentication
2. requests throttling (with different values for authenticated and non-authenticated users)
3. authorization - limiting access to certain resources (API endpoints)

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

[datnamer]

Any early benchmarks compared to say django?

[JockLawrie]

Hi Adrian,

Regarding your questions:

1. Token-based authentication. AccessControl.jl enables this in 2 ways: client-side sessions and server-side sessions. In client-side sessions the session token, as well as any other session information, is contained in the session cookie. In server-side sessions, the session token is stored in the session cookie, and any further session information is stored on the server.
2. Request throttling. Request throttling is planned but not yet implemented. I had planned to implement a one-rate-fits-all, but your idea of allowing different rates for different users/resources is a good one. I'll some thought about how best to implement this. The tools are in place though, namely sessions and the config object.
3. Authorization. This is provided at a basic level. See the tiered_members example here.

A few other thoughts:

1. A high-level roadmap can be seen in the Todo section of the Contents.
2. The docs provide working examples of available functionality, which are also found in the 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.
3. The front-end behaviour of the examples is more or less done. The next step is to harden the security of the back-end and include pen tests.
4. I'll probably announce the package as alpha in the next few weeks..see what happens.

Cheers,
Jock

[randyzwitch]

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

[essenciary]

@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.

[essenciary]

@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.

[datnamer]

Makes sense. What about Escher for the view layer? Its supposed to cover most or all of html, css etc

[essenciary]

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.

[datnamer]

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.