Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃梽馃敡 Spring (w/ Spring Boot) #55

Closed
2 of 5 tasks
Cameron-C-Chapman opened this issue Apr 25, 2017 · 29 comments
Closed
2 of 5 tasks

馃梽馃敡 Spring (w/ Spring Boot) #55

Cameron-C-Chapman opened this issue Apr 25, 2017 · 29 comments
Labels

Comments

@Cameron-C-Chapman
Copy link
Member

Cameron-C-Chapman commented Apr 25, 2017

Current Status

Todo:

  • 馃弫 Fork the starter repo & post the link in this issue
  • 馃帹 Create logo for repo & update issue status (@EricSimons)
  • 馃敤 Implement all of Conduit's functionality per the spec & API
  • 馃憖 Move repo to main org & Peer review final codebase by admins/community (RFC)
  • 馃帀 Tag v1 release and officially list it on the README!

@Cameron-C-Chapman Cameron-C-Chapman changed the title Spring 馃梽馃敡 Spring Apr 25, 2017
@battila7
Copy link

Are you going to use Spring Boot or vanilla Spring? If it's vanilla, do you plan to use other Spring projects such as Spring Security or Spring Data?

@Cameron-C-Chapman
Copy link
Member Author

Cameron-C-Chapman commented Apr 26, 2017

@battila7 I will use Spring Boot but probably just start with regular jdbc/sql. I thought starting with the simplest implementation makes sense. (although you might argue Spring Data is simpler). Maybe there could be different branches for the leverage of different Spring projects or maybe different repos entirely?

@Cameron-C-Chapman Cameron-C-Chapman changed the title 馃梽馃敡 Spring 馃梽馃敡 Spring (w/ Spring Boot) Apr 26, 2017
@battila7
Copy link

Spring Data might be simpler to use but there's too much "magic" involved, which kills the simplicity in my opinion. Therefore taking the JDBC path sounds like a good idea.

I think using different branches in the same repo is completely sufficient and much easier to manage. With careful planning and coding you can even develop the shared layers (presentation and service) on the same branch for all different persistence solutions and join them with merges.

@chencitrix
Copy link

So how should i get the services you offer? Because you have to tell me what kind of form should be used as a reciprocal way? I would like to ask a question, whether each of the exchanges have to go through the review after the test there is an unqualified threshold? Because the move here is like making a puzzled question and then becoming a sample of the nature of the study?

@Cameron-C-Chapman
Copy link
Member Author

@chencitrix I'm not sure I understand the question. Is your question about he we implement the Spring backend specifically or is this a more general question about the realworld process for merging projects?

1 similar comment
@Cameron-C-Chapman
Copy link
Member Author

@chencitrix I'm not sure I understand the question. Is your question about he we implement the Spring backend specifically or is this a more general question about the realworld process for merging projects?

@battila7
Copy link

@Cameron-C-Chapman I'm not sure about it either, but I think @chencitrix might find this multiple branch idea bad. Then the repo will not be able to provide a clean and simple solution (showcase) but is going to be a puzzle.

Although I do agree with @chencitrix in some sense, but I think it's perfectly sensible to provide multiple persistence layer options in the same repository. I think it'd be too finegrained to create different repos for this when most part of the codebase is the same.

@battila7
Copy link

@EricSimons What do you think? Is it okay to provide a JDBC and a Spring Data solution in the same repo but on different branches?
In my opinion it's too finegrained to split this into separate repos and using different branches is sufficient. Of course, it's all up to @Cameron-C-Chapman but I'm curious about your opinion.

@Cameron-C-Chapman
Copy link
Member Author

I'm open to any approach. I think being able to checkout a different branch and see that implementation quickly might be the easiest but it does add some maintenance complexity. It could also be confusing though if there were 3 repos for a Spring backend and users had to choose at that entry point. We can just get a general consensus and go that route because I'm sure people will be interested in seeing the different tools/libraries Spring has available on the backend.

@EricSimons
Copy link
Member

Tbh I'd either focus on just one implementation, or split it into two separate repos (mostly because having them on different branches will probably make exploring the repo more confusing for users visiting).

I don't know Spring/etc at all, so feel free to choose whichever way to handle this :)

@EricSimons
Copy link
Member

Just created the gitter room and updated issue status! Also, here's the logo you can use for the readme in your repo:

spring

@battila7
Copy link

battila7 commented Apr 26, 2017

@Cameron-C-Chapman What about a third solution? Having a parent repo with no source code just links to the child repos with the implementation and docs explaining the differences.
That way these closely related implementations will stay somewhat together, yet each child repo can be consumed on its own.

@EricSimons
Copy link
Member

^ that sounds awesome. I was thinking of actually having markdown files for every lang/framework in this main repo, as we're seeing more & more cases like this pop up. Maybe just create two repos for now, and we can create a markdown page w/ info that links to both in this repo?

@battila7
Copy link

That markdown idea is great and would really make this more organized! I hope @Cameron-C-Chapman is going to agree too.

@Cameron-C-Chapman
Copy link
Member Author

@battila7 @EricSimons I like the markdown idea! I'll work on getting the other repo setup and have you guys take a look and make sure that's what you had in mind. Also thanks for the logo and gitter room @EricSimons!

@battila7
Copy link

Now watching the repo, I'm sure, it's gonna be great! 馃槃

@dancancro
Copy link

I'm also implementing this blog application as a feature in my JHipster with Spring Boot example application.

The working branch is located here. So far I've just been working on converting the front end parts from this one to conform to the rest of my app and use ngrx. I should start tackling the back end pretty soon. I don't really know Spring Boot any more than I needed to to make this app. So I plan to use whatever Spring Boot conventions/approaches are easiest and endorsed by JHipster.

@Cameron-C-Chapman
Copy link
Member Author

Very cool @dancancro! I've been pretty busy lately and haven't had time to finish this up. There is some progress made on the develop branch but I know jhipster comes with some stuff wired up out of the box (JWT authentication specifically). I think they also use Spring Data so it will be a little different than what I'm doing. I'm a huge fan of JHipster and of Realworld so I'll be watching to see how it turns out. Feel free to reach out if you have any Spring Boot questions.

@aisensiy
Copy link

Finished a spring boot version here with Mybatis.

@Cameron-C-Chapman
Copy link
Member Author

Awesome @aisensiy! I only saw one issue, other than it looks great. I created the issue in your repo. aisensiy/realworld-spring-boot#1

@aisensiy
Copy link

Already fixed the issue.

@Cameron-C-Chapman
Copy link
Member Author

@aisensiy this repo looks great! @EricSimons when you get a moment from all the StackBlitz momentum could you move @aisensiy's repo over and make it official? You could just use that repo as the Spring w/ Spring Boot example and if I ever get some time to finish mine up we can create the Spring landing page repo and differentiate between the different flavors of Spring and Spring Boot.

@aisensiy the only thing I would mention is maybe adding some instructions in the readme for how to run the unit tests with Gradle? The code and the repo look great, awesome job!

@aisensiy
Copy link

Thanks for you advice. I already add some instruction for that.

@EricSimons
Copy link
Member

Just created the repo, added @aisensiy to it, and listed it in the readme! Excellent work!!

@Cameron-C-Chapman should we close this issue out? Or are there other spring codebases still in progress here? (PS - thanks a ton for the ping, stackblitz has kept me underwater lately but I want to get more active in realworld again now that it's online :)

@dancancro
Copy link

These projects are all pretty masterful. I'm torn which one to use. @EricSimons your Kotlin version is 50 files and 1972 lines. @aisensiy yours is 108 files and 5062 lines. That's a pretty big difference. Do they both achieve the same things? The file structures are quite different too. Is either more idiomatic of Spring projects?

@dancancro
Copy link

After a little investigation I found volumes of discussion about using Lombok (used in this new repo) with JHipster (used in my project) and the conclusion that it's problematic.
jhipster/generator-jhipster#4141

With all the hidden gotchas and incompatibilities sometimes I think it's a miracle that non-trivial, commercial grade, open source software ever finds a way to exist.

@Cameron-C-Chapman
Copy link
Member Author

@dancancro There are a ton of different paths possible for building applications that leverage the Spring libraries. There's not really "one" way, that's why some of the earlier discussion in this thread was around having a repo that simply served to list all the different ways people used Spring to build out the RealWorld api.

As far as the comparison of these 2 projects, one is using Kotlin which is interoperable with Java but is not Java, so it's almost like comparing a project written in 2 different languages.

@Cameron-C-Chapman
Copy link
Member Author

@EricSimons I'm fine with closing this out. I would love to finish my version up but I haven't had the time to finish it yet so I'm not sure when it will get done. What @aisensiy has is pretty similar to what I planned on doing so I think it makes sense to close this out and let this be the Spring w/ Spring Boot example, at least until some other examples get finished up and then we can decide how to organize that.

@aisensiy
Copy link

aisensiy commented Aug 29, 2017

@dancancro

The two projects have two main differences.

  1. My project has some more test cases as a demo for how to test spring boot project. And this is one of the main reason that the code lines is QUITE different.
  2. The other difference is that I use MyBatis to implement a data mapper pattern for data persistence which is much chatty than the spring jpa. But in my opinion the data mapper pattern can give more flexibility in more complicated projects. And this is just a demo to show the method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants