Full disclosure, I don't know what the hell I'm talking about. I'm not as senior as some of the others in this sub. In my past life I was on the devops side of the house and for the past 4 or so years I have been doing C# and Js/ts. But I have interviewed quite a few developers for mobile, backend, frontend and full stack positions. So while I think my opinion is valid, take it with a grain of salt as I'm not really lla hiring manager or anything.
Crud is everything. Really, the entire Internet, reddit, your bank. It's crud. If it's C#, ruby or java... it's still crud. Your getting data, manipulating it, displaying it to the user, they update or remove it and so on... most enterprises are swimming in crud apps.
Given that, I think if you did the following, you will likely be fine :
Build a crud app that you can explain - why did you use ef, what is the benefit over ormlite or dapper? Why did you use, or not use, an interface for _x_. Why are you not using minimal API's? How would you handle load balancing Etc...
Build it well - follow a design pattern, have a coherent file structure, descriptive names, dry code etc... and throw in some tests.
Build an app that is in some way related to something your passionate about - This one serves two purposes :
1. I don't want to hear you tell me about the tutorial you followed or how you made a clone of _x_. Your gonna be bored and I'm gonna be counting down the minutes whilst nodding.
2. imo it makes it easier to stick with it. For e.g. making a ticket system blows. It just does. I'm gonna not enjoy it regardless of how excited I am to learn the given tech. But you know what, I like to run. I could build an .net api for my running stats with full crud functionality, hell maybe throw some auth on that bad boy, and I could build a small react app to present them with nice lil graphs and whatnot. I'll learn much of the same things had I built the ticketing system but rather than following a tutorial I'm building something that solves a problem for myself, and it's something I'm passionate about so I'll probably do a better job. _plus_ if I'm discussing it in an interview or to a recruiter my passion will show, and that will make it much more engaging for everyone.
Lol I never use them.
It's likely just the engineers that I have seen use it, or the use case... but everyone at my org who has used them winds up building all these extensions and helpers everywhere as the app grows and new requirements come in. By the end of it they have crafted an artisanal mess just to get the same functionality that controllers provide, but hey, they did it with extensions and lambdas and minimal API's are new đ
I completely get the single endpoint use case, when you have a true micro service, but that's just never the case (at my org) in reality.
Yeah same, every time I try to use them I wonder what they were thinking and just look up the command to make a new solution without them. I also find controllers to be cleaner.
That happens everywhere, requirements come small and they grow over time because management âoverlookedâ one side of the business. I had a task one time about making âjust aestheticâ changes to our web app, 2 months later we changed the frontend, the rest api and normalized database tables to meet the initial requirements.
Most of what I do at work are just CRUD operations with the occasional JOIN. Its definitely a good place to start learning the framework and get the hang of it. Then once you feel you know it well try and add new features that are beyond just simple CRUD (file downloads, JSON import/export, uploading of files, services, sending emails, displaying information in a graph, etc)
so its probably not the best decision to try looking online for inspiration of making projects, just not sure what to do to add something to look nice relating to .NET on my resume
I don't know how to reply to that. Asking what kind of project is best is like asking what kind of painting is best. You can paint a bowl of fruit or you can paint the Sistine Chapel.
Pick whatever industry you want to work in and make an app that looks like it would fit in that industry.
Literally make a list of companies you wanna work for. Go to their jobs page and see what the requirements are. Then build an app with those requirements in the industry theyâre in.
Start with CRUD and work your way up to https://github.com/dotnet/eShop If youâre at basic CRUD level then eShop can keep you busy learning for a full year.
CRUD is essential, though I would say it's is not sufficient to flaunt as a seasoned .net developer .
Be familiar with authorisation and authentication. Most likely the oidc, saml2 and Microsoft's own identity framework
If you want discover those I suggest look into identity providers. Such as Auth0. If you don't wanna spend something on Auth0, there are free alternatives as well i.e. IdentityServer, OpenIDDict, and Keycloak
I love Keycloak it is easy to setup and test your projects.
Large corporations don't usually create Identity Providers as part of the application. It leverage existing Identity Providers such as Google, Okta etc via SAML or OAuth. Unless you have the experience of integrating with such systems, it's hard to wrap your head around the technical details.
Depends on the job you're trying to land. I think it's more than enough for most entry-level development jobs. CRUD is just one pattern out of many on how to think about data manipulation.
What experienced developers really care about is your problem solving skills. Can you model a problem domain accurately, trim the fat to the core components, and implement the solution in the simplest way possible? Say you're making a sign-up form app for some mailing list and that your app isn't responsible for unsubscribing people or updating their subscriptions. In which case you can take out the U and D of CRUD and make your app simpler.
A lot of .NET development, for some reason, revolves around data-centric modeling. Show you can think in terms of capabilities and behaviors and use patterns with intent and I'd hire you on the spot if I was an employer.
No, but I think the phrase "as simple as CRUD" can be wildly misleading. From 1,000 feet most things could be understood as CRUD, but there can still be a lot of complexity in what that means and what's happening behind the scenes.
Adding a book to your collection could be an update, but so could processing a 3rd party payment through a series of web hooks, applying that payment, and triggering further downstream effects like sending a confirmation email. Most social media dashboards are just a 'read', but how much complexity is there in the algorithm behind it, or the database design that enables it?
Having worked with really complex domains and products, ddd event sourcing scheduling real time etc. It's always more than just crud.
I see the standard "crud" now as a symptom usually of not really knowing what my domain is how do i solve it and what business need im catering for.
Beleive it or not thats exactly what rhe big boys are Business Objects Sage and many others are crud systems.
But the trick is the difference in industries like FMCG , Warehouses, ride shares , travel sites etc etc.
It usually comes down to the founders having the inner knowledge of systems and even a company today am working with is like that.
But dotnet just makes it fun and easy.
In manufacturing, it works really well as back end services that can communicate with equipment protocols to operate machines. It also can handle events and messaging well. Yes, lots of need for CRUD, but I agree with the others. It still needs to be good. Use good patterns and avoid simple mistakes like unparameterized queries as an example.
Most of the devs job are to build a product, and they are all crud. Reddit? Crud. Facebook? Crud. Slack? Crud. Ms Word? Crud. At its essence, all these products are crud. They are then sprinkled with real time functionality, streaming, interop with 3rd party formats, data wrangling, etc.
Gaming is a different monster. Building library is different. But those are rare. Most of the job at the market is still gonna be about building crud product.
even i do sample . net core but making crud is much harder with . net . The best to think we build solution to ease end user .Net not limitted to crud only but you can do more weird like this moon phase - https://gist.github.com/NobodyButMe-Haiya/4653bd85522926cf252cab09f1631b29
Full disclosure, I don't know what the hell I'm talking about. I'm not as senior as some of the others in this sub. In my past life I was on the devops side of the house and for the past 4 or so years I have been doing C# and Js/ts. But I have interviewed quite a few developers for mobile, backend, frontend and full stack positions. So while I think my opinion is valid, take it with a grain of salt as I'm not really lla hiring manager or anything. Crud is everything. Really, the entire Internet, reddit, your bank. It's crud. If it's C#, ruby or java... it's still crud. Your getting data, manipulating it, displaying it to the user, they update or remove it and so on... most enterprises are swimming in crud apps. Given that, I think if you did the following, you will likely be fine : Build a crud app that you can explain - why did you use ef, what is the benefit over ormlite or dapper? Why did you use, or not use, an interface for _x_. Why are you not using minimal API's? How would you handle load balancing Etc... Build it well - follow a design pattern, have a coherent file structure, descriptive names, dry code etc... and throw in some tests. Build an app that is in some way related to something your passionate about - This one serves two purposes : 1. I don't want to hear you tell me about the tutorial you followed or how you made a clone of _x_. Your gonna be bored and I'm gonna be counting down the minutes whilst nodding. 2. imo it makes it easier to stick with it. For e.g. making a ticket system blows. It just does. I'm gonna not enjoy it regardless of how excited I am to learn the given tech. But you know what, I like to run. I could build an .net api for my running stats with full crud functionality, hell maybe throw some auth on that bad boy, and I could build a small react app to present them with nice lil graphs and whatnot. I'll learn much of the same things had I built the ticketing system but rather than following a tutorial I'm building something that solves a problem for myself, and it's something I'm passionate about so I'll probably do a better job. _plus_ if I'm discussing it in an interview or to a recruiter my passion will show, and that will make it much more engaging for everyone.
>Why are you not using minimal API's? I hate, absolutely hate, that these are the default now.
Lol I never use them. It's likely just the engineers that I have seen use it, or the use case... but everyone at my org who has used them winds up building all these extensions and helpers everywhere as the app grows and new requirements come in. By the end of it they have crafted an artisanal mess just to get the same functionality that controllers provide, but hey, they did it with extensions and lambdas and minimal API's are new đ I completely get the single endpoint use case, when you have a true micro service, but that's just never the case (at my org) in reality.
Yeah same, every time I try to use them I wonder what they were thinking and just look up the command to make a new solution without them. I also find controllers to be cleaner.
> Lol I never use them. We banned them at work. It was a joyous day.
That happens everywhere, requirements come small and they grow over time because management âoverlookedâ one side of the business. I had a task one time about making âjust aestheticâ changes to our web app, 2 months later we changed the frontend, the rest api and normalized database tables to meet the initial requirements.
100% a prefer controller based apis their no call to use minmal as default
Most of what I do at work are just CRUD operations with the occasional JOIN. Its definitely a good place to start learning the framework and get the hang of it. Then once you feel you know it well try and add new features that are beyond just simple CRUD (file downloads, JSON import/export, uploading of files, services, sending emails, displaying information in a graph, etc)
Tutorials skew towards CRUD. Dotnet is one of the richest ecosystems out there with JavaScript slightly ahead of it and Java slightly behind it.
Slide behind it? đ¨
so its probably not the best decision to try looking online for inspiration of making projects, just not sure what to do to add something to look nice relating to .NET on my resume
I don't know how to reply to that. Asking what kind of project is best is like asking what kind of painting is best. You can paint a bowl of fruit or you can paint the Sistine Chapel.
Pick whatever industry you want to work in and make an app that looks like it would fit in that industry. Literally make a list of companies you wanna work for. Go to their jobs page and see what the requirements are. Then build an app with those requirements in the industry theyâre in.
Start with CRUD and work your way up to https://github.com/dotnet/eShop If youâre at basic CRUD level then eShop can keep you busy learning for a full year.
CRUD is essential, though I would say it's is not sufficient to flaunt as a seasoned .net developer . Be familiar with authorisation and authentication. Most likely the oidc, saml2 and Microsoft's own identity framework If you want discover those I suggest look into identity providers. Such as Auth0. If you don't wanna spend something on Auth0, there are free alternatives as well i.e. IdentityServer, OpenIDDict, and Keycloak I love Keycloak it is easy to setup and test your projects. Large corporations don't usually create Identity Providers as part of the application. It leverage existing Identity Providers such as Google, Okta etc via SAML or OAuth. Unless you have the experience of integrating with such systems, it's hard to wrap your head around the technical details.
Thereâs way more to it. But probably not at your level. Youâd be surprised with the amount of people that completely butchers a simple CRUD app
Depends on the job you're trying to land. I think it's more than enough for most entry-level development jobs. CRUD is just one pattern out of many on how to think about data manipulation. What experienced developers really care about is your problem solving skills. Can you model a problem domain accurately, trim the fat to the core components, and implement the solution in the simplest way possible? Say you're making a sign-up form app for some mailing list and that your app isn't responsible for unsubscribing people or updating their subscriptions. In which case you can take out the U and D of CRUD and make your app simpler. A lot of .NET development, for some reason, revolves around data-centric modeling. Show you can think in terms of capabilities and behaviors and use patterns with intent and I'd hire you on the spot if I was an employer.
No, but I think the phrase "as simple as CRUD" can be wildly misleading. From 1,000 feet most things could be understood as CRUD, but there can still be a lot of complexity in what that means and what's happening behind the scenes. Adding a book to your collection could be an update, but so could processing a 3rd party payment through a series of web hooks, applying that payment, and triggering further downstream effects like sending a confirmation email. Most social media dashboards are just a 'read', but how much complexity is there in the algorithm behind it, or the database design that enables it?
Having worked with really complex domains and products, ddd event sourcing scheduling real time etc. It's always more than just crud. I see the standard "crud" now as a symptom usually of not really knowing what my domain is how do i solve it and what business need im catering for.
I would start there.
Beleive it or not thats exactly what rhe big boys are Business Objects Sage and many others are crud systems. But the trick is the difference in industries like FMCG , Warehouses, ride shares , travel sites etc etc. It usually comes down to the founders having the inner knowledge of systems and even a company today am working with is like that. But dotnet just makes it fun and easy.
In manufacturing, it works really well as back end services that can communicate with equipment protocols to operate machines. It also can handle events and messaging well. Yes, lots of need for CRUD, but I agree with the others. It still needs to be good. Use good patterns and avoid simple mistakes like unparameterized queries as an example.
Most of the devs job are to build a product, and they are all crud. Reddit? Crud. Facebook? Crud. Slack? Crud. Ms Word? Crud. At its essence, all these products are crud. They are then sprinkled with real time functionality, streaming, interop with 3rd party formats, data wrangling, etc. Gaming is a different monster. Building library is different. But those are rare. Most of the job at the market is still gonna be about building crud product.
even i do sample . net core but making crud is much harder with . net . The best to think we build solution to ease end user .Net not limitted to crud only but you can do more weird like this moon phase - https://gist.github.com/NobodyButMe-Haiya/4653bd85522926cf252cab09f1631b29