I am a Software Developer working mainly in Go and PHP.
Nothing here yet.
No blogs yet.
Browsers will never ship with a transpiler, but there is a major effort being made to ship web assembly. This will allow a common language to be compiled to. I think that is kind of along the lines of what you are talking about.
From what you have said I assume you are building server side application, if not, that would basically invalidate this response. With that assumption intact, sessions are definitely the way forward. They are easier to deal with and reduce the logic needed. I would always go for the simpler option. Just to be clear, JWTs are not insecure. Uses of JWT's are insecure. There are implementations of OAuth2 that use JWTs, can invalidate the token, and are secure.
As with most things, this depends on your use case. In API's JWT is the probably a better choice. In a front end server side application sessions are probably the right path. That being said, there are use cases where you need to use JWT instead of sessions and visa versa. There is no one way with this.
I would build, with lots of security help, a single store for peoples information. You could set your address, back details, phone number, etc. You would then grant permission for companies to access subsets of your information. So when you move, you change your info once, and all companies would automatically get updated with your new info. While this is totally possible now, the security goes a little over my head, and getting everyone else to integrate would be a huge mission.
I think what you are looking for is an OAuth 2 server. PHP League OAuth 2 is a really nice one. The server application acts as your central login. All other apps will refer to that server for authentication, authorisation (scopes) and so forth. You should probably do some reading about the flows and security of OAuth 2 before you embark upon this route, but it sounds like it will fit the bill.
That depends on your situation. If you have a small app that only queries a Model in a specific way in one place, then you may be prematurely adding complexity. If however your use of model queries (including creates and updates) start to get reused, then Repositories are a must. Try not to duplicate code when querying your Models, as it makes making changes error prone. The other use for the Repository pattern is to setup a data domain (Your domain is the modelling of data that does not necessarily match your database structure). You would then setup the Repositories the model your domain, which in turn queries your Models which model your database. Hope that helps.
server-less architecture refers to services that allow you to run your code without knowledge of the server it is being run on. In the case of AWS Lambda, you upload your code and tell it the entry point file and function, and it runs that function, scaling as necessary. You actually have almost no control of how it is run (you can tell it the amount of RAM you need). It is not that there is no server, it is just that the server is irrelevant and out of your control. Hope that helps.
@j Completely understand and appreciate your point of view, although hello world in C usually doesn't involve memory allocations and callstacks (unless you were hello worlding in inline asm :) ). I understand every point of view that is opposed to C in a degree structure. I have however worked in many companies, with many different developers and I found that those that learned C as a degree (read starting) language had a better understanding of what was happening under the hood, then those that starting on "simpler" languages. So i suppose my experiences would always lead me down the Yaya for C road.
While I think you are probably right on the whole, the flip side of the argument is that C pointers teach and show an understanding of addressable memory. Also a fair number on languages are C-like or C-based, so to transition to some other languages might be easier. I personally found learning C in my CS degree helpful and informative, but that is just my opinion.