In Node, you would commonly reach for the builtin core "node:crypto" module to run cryptographic functionality like this. I wondered why that wasn't used here, but bcryptjs was. After digging into it a little, node doesn't ship with core support for bcrypt, because it's not supported by OpenSSL.
The node crypto module is essentially an API that offloads crypto work to OpenSSL. If we dig into OpenSSL, they won't support bcrypt. Bcrypt won't be supported by OpenSSL because of reasons to do with standardisation. https://github.com/openssl/openssl/issues/5323
Since bcrypt is not a "standardised" algorithm, it makes me wonder why Okta used it, at all?
I remember in uni studying cryptography for application development and even then, back in 2013, it was used and recommended, but not standardised. it says a lot that 12 years on it still hasn't been.
In my final semester of uni, we did an "AI" module, which involved using prolog. I didn't really grok it until the night before the final exam. Felt like I had a bit of a beautiful mind moment with all the possibilities opening up to me when it clicked.
This was my only 100% final exam module with no continuous assessment/midterm papers or exams/projects to pick up slack if I failed, so I was nervous going into it. Kinda felt like my whole degree weighed on it. That night before, I just *got it* and it made all the difference in the world. I got how powerful it is, and why to use it.
Do you, or anyone else in the team or community, have a good resource you would recommend to people complaining about "too much boilerplate" in redux code? It is likely the most common complaint I see, that I understand to come from a place of people not understanding it this a tool best used for scaling and/or already big projects. Whenever I have worked with Redux in a large project, that "boilerplate" is minimal and the benefits obvious.
Yeah, as I talked about in both the original blog post and my parent comment, we've specifically designed Redux Toolkit to eliminate the "incidental complexity" that came along with using Redux [0]:
- Immer makes writing immutable updates easy, because you can write "mutating" logic like `state.todos[5].completed = true`
- `configureStore` sets up a Redux store with good defaults (DevTools extension, thunks, mutation checking) in a single line of code and has easier-to-read options if you do need to tweak the config
- `createSlice` eliminates the need to write any action creators or action types by hand
- Our new `createAsyncThunk` and `createEntityAdapter` APIs (new in v1.3.0 [1]) simplify the common use cases of dispatching actions as part of data fetching and managing normalized data in your state
Also, RTK is written in TypeScript, and designed to infer as much as possible. For example, if you declare the type of the action payload in a `createSlice` reducer, the generated action creator has its payload argument typed automatically to match.
Meanwhile, the React-Redux hooks API generally requires less code than `connect` does, and is easier to use with TypeScript as well.
Finally, we're now encouraging folks to use the "ducks" pattern for single-file Redux logic [2], which cuts down the number of files you might have to work on for a given feature, and using `createSlice` basically gives you ducks files for free [3].
I think that complaint usually comes from people who try to put everything related to state in Redux, and not just the parts of it that need to be.
Also the 'reducks' pattern of splitting the Redux state into separate files, each containing a reducer and the related actions and selectors helps keep things simple to understand (although I guess it is a bit more overhead, actually).
What are the obvious benefits other than fundamentally dumping shared data into a global singleton?
How do you handle testing of connected components? There’s tons of pain points. I’m on a pretty large Redux project too, and every day I wish I could just simplify the whole app (as we scale) by removing Redux.
I don't know if I agree... I've used "traditional" Redux in very large projects and the boilerplate far from minimal, and it grows in the same scale the app grows. And it's in the parts that grow more, which is app code: action types and action creators are very un-DRY and repetitive. Switch statements are way noisier syntatically compared to other solutions such as classes or objects (used in VueX and RTK createSlice). Etc.
I think it speaks volumes when the Redux maintainers are going into a direction that uses less boilerplate, like Redux Toolkit.
Honestly, there's nothing wrong with boilerplate, but I guess it's time to admit that some people love it and others hate it.
I think it's important to distinguish between the "inherent" complexity" and "incidental" complexity in using Redux [0].
Dispatching actions and writing reducers is _inherent_ complexity. It's part of Redux's design, and is a deliberate level of indirection.
Having to write nested spread operators to perform immutable updates, switch statements in reducers, and `const ADD_TODO = "ADD_TODO"` is _incidental_ complexity. Nothing about Redux's core design _requires_ you to write the code that way. There's valid reasons why those patterns exist [1], but writing a reducer with a switch statement vs a lookup table doesn't change how the Redux data flow behaves.
My goal is to eliminate the incidental complexity, because it's not necessary and does present a barrier to people learning and using Redux.
hooks and the context api are great for small projects. Check out the hooks comparison section in the linked article to understand how it might fit your app. It references other good resources, too.
This attitude is why silicon valley is well on its way to becoming the villain in the narrative of our progress. It is a place dedicated to redefining the world we live in. Valley companies can, and regularly do, redefine how companies work and make money. Sometimes they need to be the ones to bite the bullet and lose some of their yearly profits by spending it on making this transition buttery smooth.
Without them trying to make this effort, and the common man fearing the gaze of the innovation beast, governments will have to act - and not necessarily by transition those affected into positions where they can still be secure, but by stifiling the innovation by actively targeting the catalysts of these changes with laws and regulations and hoops upon hoops to jump through.
The good news is, for the average user, unikernels are pretty much guaranteed to be mainstream and streamlined at some stage in the future, thanks to Docker acquiring Unikernel Systems, and the awesome work that the like of deferpanic are doing. :D
Well you'd think it's not really necessary to run Android in a VM. The Android x86 project should make it easy to run atop an existing Linux in a container.
Just as an aside: Docker doesn't seem very security-focused, I would not [yet] count on its containers being properly sandboxed. :>
They're pretty sandboxed, but every Android app gets a JVM, no exceptions allowed (even Android's pure C++ API is just a wrapper around JNI calls). And in the case of the old Dalvik VM, it's a terrible JVM.
> They're pretty sandboxed, but every Android app gets a JVM, no exceptions allowed (even Android's pure C++ API is just a wrapper around JNI calls). And in the case of the old Dalvik VM, it's a terrible JVM.
Wasn't Dalvik deprecated & replaced by ART (Andriod Runtime)? ART compiles apps AoT - IIRC; upon installation pre-Marshmallow, and while charging/idle Marshmallow going forward
Yep, hence me specifying the old one. ART cleans up a lot of things: no more 8-16KB main thread stacks, better code gen via AoT, fully precise collection, moving GC. It has some really ingenious features as well, like switching to a compacting GC with better throughput and space efficiency when an app goes in the background and latency is irrelevant. The switch to ART as default was actually in 5.0 (Lollipop).
It's almost enough to make me stop cursing Android developers and their children's children. Unfortunately version updates for non-Google devices are rare and everybody is still stuck supporting the majority of devices that are pre-Lollipop. Also it didn't make the APIs any better >:(
The node crypto module is essentially an API that offloads crypto work to OpenSSL. If we dig into OpenSSL, they won't support bcrypt. Bcrypt won't be supported by OpenSSL because of reasons to do with standardisation. https://github.com/openssl/openssl/issues/5323
Since bcrypt is not a "standardised" algorithm, it makes me wonder why Okta used it, at all?
I remember in uni studying cryptography for application development and even then, back in 2013, it was used and recommended, but not standardised. it says a lot that 12 years on it still hasn't been.