Posts

how would I test microservices?

Well. Imagine that I would have simple microservice that is small Express application that serves data from DB and transforms it. First I would think about proper design of code. I would split code into: initialization part (creating Express app) - smoke tests would be sufficient Express endpoints - they will be set appropriate headers and integrate logic and DB. I would tests more overally - if headers are correct etc. logic - this is meat, so I would test more thorougly this. Logic would be probably in pure functions. Easy to test. (that's one of reasons I don't want to put to much logic in endpoints themselves because they are harder to test). wrapper for DB - I would test e2e with some kind of development database in play. Maybe I would also make some kind of automatically generated tests for endpoints. I mean. I would already test logic so no need to duplicate code, but to ensure that endpoint really returns logic. I would probably make functions l
Post a Comment
Read more

ways of using React context

From what I observed React context is used in many ways: As simple value (e.g. string, number, boolean) As object As immutable object (i.e. if you want to change something in context you trigger appropriate update to component which render Context.Provider As mutable object (i.e. if you want to change something in context, you mutate context directly. I usually work this way that have main app context which is mutable and contains some "global" variables and some methods for making global changes. I think mutable React context is harder to maintain. And context always sounded like some escape hatch for access/write to global state. And I usually won't have too many contexts. In small app there would be one React context. In bigger apps I could think about some others, for some specific parts of app or maybe for some specific aspect of app (e.g. UserContext, ToDoContext etc.) And context for me means usually object. In React do
Post a Comment
Read more

classes as state manager React

You don't need Redux or any management system in React. You know this, right? Right? But seriously people usually when they don't use state manager, they just use useState and context. And it can be sufficient. But not always. Sometimes you need global state management, but Redux and different state managers are just inconvenient They force immutability (you can mitigate it with libraries like immer, but still). They often force you to use some kind of actions What's your options? If there was a way that would allow to use plain JS objects and classes for state management. Wait? Do I mean Mobx? Well, conceptually, yes. But the truth is you don't need ANY library for this. Mobx just wires JS objects to updates. But the thing is you can do this your self. Just write normal JS classes and put reactivity into them. You can know think that's reinventing the wheel, but I will say it's super simple: class Entity { subscribers = []; state = {};
Post a Comment
Read more

what are entity objects?

Entity... it's a word that it's often related with Domain Driven Design, but I won't write specifically about DDD. What I want to write, can be used without DDD approach. I think DDD is somewhat conceptual heavy and it's often useful to use terms popularized by DDD but without all this weight. So. What's entity? Let's assume it's a JavaScript class (actually it doesn't have to be a class, it's more conceptual term, but now I assume some specific implementation of this). So... each JavaScript class? No. It's more like something that has specific identity. e.g. User, Product. Usually you have many things of some type (e.g. many users), but this concrete user (represents in database by specific row, but in app you would create instance of User class for example). On the other hand if you have something that is more of a utility class - e.g. imagine that you have Theme class with colors, backgrounds - this thing is probably not entity (thou
Post a Comment
Read more

React project: how to structure?

how to organize React project to ensure maintainability? separate configuration - instead of putting all in your "normal" files (e.g. files with React components), it's better to put "configurable" things in separate file. What's are configurable things? E.g. urls for API endpoints, route names, translations etc. dev mode - it's useful also separate your configuration for debugging or testing from the production one. You could also have some feature flags somewhere in your app to enable devs to comfortable debugging e.g. special buttons for doing something useful for programmer, that has no sense whatsoever in production mode. Sometimes it's useful to have some "sandbox" views. separate components into files - rule of thumb can be thought as "each component in different file" but this has not always to be true. Sometimes you could put multiple smaller components in one file if they are related/part
Post a Comment
Read more

Learning Nest.js

I'm learning Nest.js. I'm going to have job interview and this job demands Nest.js. Well, before I had quick contact with Nest.js and I thought "this is overengineered". And when returning, I still think this is a case. I think Nest.js is heavily engineered framework and I wonder "why is it popular at all?". I mean Angular is frowned upon, and Nest.js is like Angular. I think though there's some added value in Nest.js and I think this value lies in standardizing your code. Nest.js is a framework so you have to put your code in predetermined places. And this alone saves case of Nest.js. This framework doesn't solve technical problems, this framework solves problems with people having various opinions (because it is quite opinionated). And people, if you are programmer, are usually your main problem to solve.
Post a Comment
Read more

SPA - tips

Few notes on how to make SPA: start with model. Don't care about GUI on the very beginning. Start writing basic classes in pure JavaScript and write unit tests for it. E.g. if you do Todo List, make some classes like Todo, TodoList etc. Think in concepts of domain knowledge rather than GUI. but remember that your models should be reactive(or it should be easy to add reactivity). You can start right away with reactive code using some reactive library like Redux or Mobx, or you can add this reactivity later (simple addon is using some kind of observer pattern - e.g. via EventTarget It's useful to have same models on backend and frontend but it's not always be the case. Anyway, think also how you will connect backend with frontend and how you implement reactivity For GUI you can use library with component paradigm e.g. React, Vue, Angular. Think on how you will connect and integrate your models with visual components. Do models contain everything you will need? Or d
Post a Comment
Read more