261–270 of 453 posts
For websites, just Ruby on Rails hosted on Heroku with Postgres. For web applications React with optional state management (Redux Saga / Mobx) for the front, hosted on Netlify. Ruby on Rails in API mode, with Postgres running on Heroku if the API is non real-time or high traffic / spiky. Go with DynamoDB if it is.
Earlier quoted context omitted.
Although I think it's not a big issue, I'd look into Vue instead of React. Imo it's simpler and give you a more complete solution out of the box (routing, reactive data layer). Now, I've barely tested Django, but I would not go the python way unless you have a good (other) reason. Rails seems to have a much more developed web development community. Node might be a great choice due to you being able to use the same la…
> Now, I've barely tested Django, but I would not go the python way unless you have a good (other) reason. Rails seems to have a much more developed web development community. Having used both Django and Rails extensively recently, I disagree. Maybe 5 years ago, yes. For two examples I ran into yesterday, check out https://github.com/rails/rails/issues/32790 and https://github.com/rails/rails/issues/31419 which featu…
- On the frontend, use React with TypeScript. Create React App now makes it dead easy. Just do: npx create-react-app myapp --typescript - Do not use redux until you know React well. You might not need it. If you do need it, use `redux-starter-kit` offered by the core Redux team. - For backend, just use Django (or Rails). Elixir's Phoenix is also very well thought out. - If you use node: express, sequelize. Async/awai…
> just use Django (or Rails) What do you mean by "just use"? The OP seems to have a long experience and having had used Rails recently myself as a 20 years experience web developer, all I can say is stay away if you know the way web works and not doing it as a medium team size. You need to learn everything the rails way even if you know every moving parts of what makes a web site which can often get in the way and I…
I am surprised no one has mentioned Pyramid and SQLAlchemy yet. SQLAlchemy is by far the most complete ORM/Query-Builder I have used (yes, I have tried out Rails, Django and Hibernate). Also Pyramid's traversal routing is awesome to build REST-applications and ACL authorization. What ever stack you decide on, I recommend to stay away from too much magic as it complicates debugging and understanding the framework comp…
It builds on years of prior experiences and it shows in how mature and pleasant it is, they didn't have great marketing but the project deserves more recognition from community.
Earlier quoted context omitted.
Wow. What an incredibly ignorant and embarrassing point of view. > Redux is not too hard, but it's poor in design. You have not once yet stated why it is "poor in design". > Also you will have to give up redux soon, the hype is over and better things are at the horizon. I do not care for hype. I am embarrassed for you that you use hype as a measure of a technology's quality. > There is definitely some pride in dev's…
Wow, relax man! You don't have to defend redux with your life! I have to work on a daily base with redux because almost every stupid company is using that nowadays. Some codebases are so horrific that I simply quit the job and find something better. I actually said why it is poor in design: endless switch statements with reducers, do you think that is great design? Every component that wants to use a store needs to '…
In any action.ts file you can have as many actions as you wish. Every action has type, dispatch and reduce methods:
export namespace indexSaveSsl {
export const type = 'INDEX_SAVE_SSL';
export const dispatch = (store, response) => {
store.dispatch({
type,
data: response.data
});
};
export const reduce = (state, action) => immutable(state)
.set('Reports.data.ssl', {})
.set('Reports.data.ssl.result', action.data)
.set('Tools.options.ssl.test_running', false)
.value();
}
This is how actions is combined:
export const actions = (() => {
// import main actions via webpack
const actionsMain = require.context('app/', true, /actions\.ts$/);
const mainFinal = actionsMain.keys().reduce((prev, key) => Object.assign(prev, actionsMain(key)), {});
return mainFinal;
})();
actions.indexSaveSsl.dispatch(store, resultSsl);
const reducer = (state = {}, action) => {
// main reducer
const result = Object.keys(actions)
.filter((item) => actions[item].type === action.type)
.map((item) => actions[item].reduce(state, action));
return result[0] || state;
};
createStore(reducer, hydrate, extension);
Earlier quoted context omitted.
I agree with all this, though if you're deadset on React (which is a great choice) and you know JS well, then I'd say Express is a better choice than django. Also > Do not use jwt I heavily disagree with this. JWT has its trade offs sure, but if you want to start simple and have the most "cookie like" experience then use cookies and store your JWT inside the cookie. Edit: To be clear, to get started you should use wh…
What is the purported benefit as opposed to a shorter cookie that is the key for an expiring record in redis that contains whatever session information the JWT would have? And it scales... The JWT would just continue to grow in size and increase request response size... And you'd have TWO expiration dates (on the cookie and in the JWT).
JWT is a pain in the ass for a lot of reason people don’t appear to understand until they actually try to use it; and the majority of the proponents for it appear to have never actually used it seriously and had to deal with issues like, oh wow, redis is now the bottleneck for my ‘stateless’ authentication.
Unless you need it and can articulate why, with no magic hand waving... just. use. cookies.
...and ffs, dont just put your jwt in a cookie, thats stupid...and if you don’t understand why, you shouldn’t be using jwt.
PHP /laravel and react.
Yep. In the past years Laravel has helped us quickly build prototypes that we could conveniently grow into enterprise-scale apps. Backend: PHP/Laravel Frontend: Same, using VueJS as needed/wanted. Database: Usually starting off with SQLite and switch to a more appropriate choice like Postgres, MariaDB or even MSSQL.
If it wasn't for PHP I think Laravel would have overtook Rails as the tools to build prototypes.