Looking for insight about the architecture of an ads website

[TomPich]

Hi guys,

I might have an interesting project in the coming months. For now, I have to give a quote for this job.
The project is a website where different kinds of users could post ads about pets for adoption or for sell.
This means that I must be able to handle hundreds of users with an account (three different kind of accounts : private, association and animal professionals) and hundreds, maybe thousands of pets.

My first thought is : PW + AlpineJS. I read that PW is capable of handlings hundreds of thousands of pages. I begin now to be quite familiar with PW API, and AlpineJS would let me bring some interactivity.

My second thought : PW headless, acting as a REST API provider, and Svelte for the front end (I never used Svelte, but it seems nice and quite light weighted, it would be an occasion to learn on a real project – I learned a little bit of React but never had the occasion to use it for real projects). I’m afraid Svelte would be a bit of an overkill, I don’t really need advanced reactivity and all that. But it could be a way to broaden my horizons.

My third thought : Laravel for backend (never used it – I’m a bit familiar with Symfony, but Laravel seems more light weighted). The publishing needs are not big : create an account, publish a pet file. And that’s it. So maybe (maybe !) a PHP framework would go straight to the point. I could even develop it from scratch, but I don’t trust myself 100% about security.

What would be your choice ?

Any clue about the time you would need to do that ? My guess is about 80-100 h for the first solution.

I am very eager to hear some experienced guys' opinions...

Thanks in advance.

[wbmnfktr]

My biggest issue with this - in terms of coding and stitching everything together - would be registration, user management, page creation through registered users, and keeping everything as easy and clean as possible for the users. They need custom interfaces and can't use the ProcessWire backend. They probably wouldn't get it.

Second issue would probably be an additional management tool for all ads, users, and tasks that occur on a day to day base for such websites aka things user need help with. Maybe a bit of GDPR to allow users to totally delete their account and all their ads while keeping everything that might need to be archived by law.

You didn't mention any form of payment process so things should be quite straightforward from here.

For the frontend I'd go with clean PHP, clever site structure, and logic. Search, sort, filter with any kind of JS is nice, but not necessary.
Later on I might add some nice and shiny AJAX-powered search bars, and things like that.

BUT... all of the above isn't the problem with such projects.

What you really need is a clear and precise description of what the client thinks he wants, written agreements about who delivers which part and who is responsible for what.

Was asked to create a job board once.
Client said: "Super easy. User creates an account. Adds job postings. List them on the website. Remove them after 30 days. Nothing special!"

What he really wanted was a rebuild of monster or stepstone of one of those big job portals. So... yeah.

How long would it take? At least 30k EUR.

[TomPich]

I agree, users must not use PW backend. I was thinking of a custom backend (my account / my ads / CRUD for each ad) and then use PW API to manage that. I recently dived into the page / template / field management API, and it’s quite simple and straightforward.
And I also agree, JS is not necessary – it’s just for things to be smoother and nicer, like an AJAX search result display.
You are right about GDPR. I need to investigate a bit more about that.

So if I got you right, you would go with a from scratch PHP backend ?

[bernhard]

12 hours ago, wbmnfktr said:

Was asked to create a job board once.
Client said: "Super easy. User creates an account. Adds job postings. List them on the website. Remove them after 30 days. Nothing special!"

What he really wanted was a rebuild of monster or stepstone of one of those big job portals. So... yeah.

Haha, so true. How often have I heard "super easy, super simple..." ? 

2 hours ago, TomPich said:

I agree, users must not use PW backend.

I agree with most of what @wbmnfktr said, but IMHO if you don't use the PW backend you probably lose one of the main advantages of PW over laravel et al. You have to build all the forms, all the logic and all the underlying concepts on your own. Have a look at https://www.youtube.com/watch?v=MYyJ4PuL4pY for example. When you watch this video you'll see so many things that are so much quicker when using PW + backend.

Do I say you should use the PW backend? No, but it's probably too early to ditch it. If the design is important it's probably easier to build something on your own, but it sounds like a quite technical project with tech-savvy users I guess, so using the PW backend should work quite well?!

You could also just replace the things you want to have different and build your own admin theme. For example you could totally replace the main menu bar / header and leave everything else as it is. 80-100h sounds sporty to me ?

 

[MarkE]

1 hour ago, bernhard said:

Do I say you should use the PW backend? No, but it's probably too early to ditch it.

@TomPich I think the decision re the PW back-end is quite critical in terms of time estimation. Using it will save a lot of coding for an app like this. But a custom CRUD interface, if well-designed, might be easier to use. For my membership app, I went with a highly-constrained PW backend provided through modals (my "AdminInModal" module), in a front-end wrapper, which limits users to just their data for specific pages. The system has about 200 non-techy users who have no problem with the interface.

 

1 hour ago, bernhard said:

80-100h sounds sporty to me

+1 

[bernhard]

10 minutes ago, MarkE said:

For my membership app, I went with a highly-constrained PW backend provided through modals (my "AdminInModal" module), in a front-end wrapper, which limits users to just their data for specific pages.

Yeah, that can be a good approach, see https://youtu.be/7CoIj--u4ps?si=q1RnzHLNWwt15TlE&t=1715 (ALFRED) for this. It might not be the 100% solution (in terms of UI/UX), but it might probably be the best in terms of cost/benefit.

 

[wbmnfktr]

5 hours ago, TomPich said:

So if I got you right, you would go with a from scratch PHP backend ?

Oh no no no... it would be ProcessWire front, back, and center. But I wouldn't use anything like Svelte or whatever on the frontend or even go headless in this case.

 

In addition to that, when I spoke about custom interfaces and management tools I meant things like we can see in the Invoice Site Profile.

[TomPich]

I just wrote a first draft of the precise specifications... And gosh, that would be a tremendous work to do with a framework.

So, I think, as you all pointed, that it would be better in terms of cost/benefit, to use PW admin. This project has no profit objectives. They want to raise funds by donations and crowdfunding for the website. I thus have to offer them the best cost/benefit ratio (end still pay my bills at the end of the month ? ). The design is not that important. But most users won’t be tech-savvy. So it has to be simple and straightforward.

That being said, I didn’t explore how to twitch the admin theme in PW (that was next in my PW ToDo list). It would be a great occasion.
I recently thought about using exclusively the Dashboard module for some restricted user accounts in a website I’m doing – and I don’t even know how to do that.

Any suggestion about tutos and posts that could help me explore this aspect of PW are very welcome (I took note of your YouTube video, Bernhard, and will watch it ASAP).

Thanks guys, as always, for your help and your time. Much appreciated. ❤️

[wbmnfktr]

9 minutes ago, TomPich said:

This project has no profit objectives. They want to raise funds by donations and crowdfunding for the website.

That sounds to me like a totally different project now.

This way you could offer a solution that's managed. In other words: the frontend lists all offers/ads, categories, filters, and everything you need. When it comes to posting ads they could all be collected by a more or less simple form (FormBuilder would work perfectly well here). In case of shelters that have a whole lot of animals they want to list, they could send a CSV (or Excel that needs to be converted) and you or someone imports it via ImportPagesCSV. Even references to that animal shelter profile could be set and other things of course.

The inital cost would way lower, the project could grow and it would only be necessary to build what is really needed, and you could offer to manage that site for a monthly fee.

Start with a minmal solution and go from there. We did this with a restaurant directory completely managed, no registration needed.

But that's just my thought before my first coffee. ?

[cwsoft]

Hi,

still sounds doable with plain PW to me. I would go with a frontend login to allow users to login to protected areas of the website frontend from where they could add pets via templates or module logic. Would limit the users to just see the frontend parts they need without beeing able to enter the backend. Did something like this with up to 10.000 users for a kind of booking portal. 

[TomPich]

Sounds great. It would cover my needs.

Do you treat these users as PW users? Or did you make a kind of "front user" profile using a custom template? In the last case, i wouldn’t be so sure on how to handle security matters and sessions.
 

[cwsoft]

1 hour ago, TomPich said:

Sounds great. It would cover my needs.

Do you treat these users as PW users? Or did you make a kind of "front user" profile using a custom template? In the last case, i wouldn’t be so sure on how to handle security matters and sessions.
 

I created regular user accounts via the PW API with a specific role. Then I build a frontend login form using the PW API with the build in login throttle module and added a hidden honey pot field and a simple number captcha. Doing so allows to not expose the true admin login URL, which I keep for the side admin and two maintenance accounts. The admin template checks for the roles and throws a 404 PW error if a user with the role of the frontend-user would try to enter any backend page. So for those frontend users it seems the PW admin backend does not exist at all, while the site admin or the two other accounts can enter the PW backend parts which are accessible based on their roles and permissions granted. 

Edited May 11 by cwsoft