= An open-source full-autonomous smart greenhouse that is connected with your devices! The software was written entirely by me for a university project :) = Not sure if you’re looking for feedback here but on the IoT side: Sequence should probably take in an enum rather than a string GreenhouseManager running through a big if/else block on startup runs the risk of only showing one meaningful error at a time. It would be much more convenient to build up a list of error conditions and throw only if that list isn’t empty with the combined results (you can take this as far as you want — you can encapsulate said list in a class, for example). This eliminates your inner try/catch block, the nesting of which is almost always an anti pattern In general, really great work! Hope it’s ok to have given some feedback, and best of luck with this and your ongoing startup Thank you very much I was initially thinking of making it a startup of sorts since there are no smart greenhouses on the market that use soil (most use hydroponics because it requires less attention) but I preferred to publish the project as open-source since I am already working on another startup loving this! can you add maybe a small section which plants have been tried and what the produce could be per time x? currently I only have seen "6 plants" so that could be tomatoes I guess? Of course! As soon as I finish my university exams I will add it to the readme file of the GitHub project! I preferred not to specify the plants tested as you can put any plant with this product, you just need to have enough space I'm curious since you basically did whole stack development which part/layer/technology was the hardest part? My only request is that you make the home directory config use XDG_CONFIG_PATH and or put the dot config directory in $HOME/.config instead of directly in the home folder I'm also kind of curious why you chose GraphQL instead of just doing a traditional REST Open API? Is the data that sparse and or is there lots of connections? I admit I'm biased on GraphQL as I its kind of painful for typed based languages. Some languages precompile the query schemas into Classes but it doesn't look like you are doing that (I thought there was TS support for that but maybe not) React relay does auto generate types. The types are generated on a per query/fragment basis. Pregenerated classes based on schema wouldn't make sense for most graphql stuff you only want a subset of the properties it causes mapping issues. Typescript and languages with similar type systems work really well because types are kinda generic by default as in they accept any superset of those properties The issue I have with graphql in general is that in any situation where you can't use projected queries the serverside graphql becomes quite tedious for minor benefits in flexibility of consumption and payload size. If you are the only person generally consuming your API and you generally need the whole graph, don't do graphql imo.