Calling all devs: View our source code

Off-topic Announcements
#1

Since 2002 we’ve developed custom software for LB, whether that’s for the site itself, to customise third-party forum software we used to run, support migration efforts as we moved from code-base to code-base over the years or various other utilities and web-services for our different projects.

We’re now running LB on an open-source discussion platform so there’s no huge amount of development for us to do, which is great as we became more and more resource constrained as the years went on, because… life. We’re still coding, still working on things such as a new galleries site and what-not.

Over the years we must have written hundreds of thousands of lines of code (perhaps more) and created untold number of graphics and HTML designs. Rather than let it all die a death hidden away from everyone I thought it would be nice to put it out there for posterity.

With that in mind, you can find all the source-code for our historic projects on GitHub now:

We’ve got on there, source code for:

  • The original LB website (V5)
  • The forum-only LB website (V6)
  • MotoProfessional (our photography sale website)
  • Stolen Vehicle Database (SVD)
  • Email Loader (helped automate editorial publishing to LB)
  • MotoFeed (a project we didn’t finish)
  • VehicleDatabaseWebService (VDWS - used by SVD)
  • Other utilities
3 Likes
#2

V5 was my favourite of the LB websites. I regret moving away from this. We should have just modernised it.

#3

well here’s a question: I believe in the single page site I feel it’s the optimum solution (at times unattainable potentially so an ideal case). Looking at V5 there does appear to be lots of static loaded tabs - how would you modernise? It’s looking like a major rewrite either way, a dashboard with news, gallery etc widgets?

1 Like
#4

The value of the V5 code-base is it’s very mature Content Management System in the middle-tier, the application that acts as API and data abstraction layer. Without considering whether it would be viable, i.e. a desirable service or even if migrating to a different product like DNN, Umbraco etc would be a better course of action, as a mental exercise, if we were to consider modernising it then I would consider the obvious goals to be:

  • Give it a first-class mobile experience
  • Give the photo galleries a slick, ultra-high definition experience
  • Make the editorial compliment video components
  • Trim off the other outdated aspects, i.e. directory

So I’d probably approach it like this:

  • Create a new Web-API for the CMS (application tier), say .NET Core Web API
  • Move file storage from local files to cloud storage
  • Create the front-end app that consumes the API from your favourite poison
  • Configure the front and back-end to use OpenID Connect to authenticate users against our IDP
  • Consider either containerising the app or using a managed platform like Azure Web Apps

So many good front-end options nowadays, i.e.

  • An SPA architecture
  • An MVC architecture
  • A Web-Assembly architecture, aka WASM (server or client side), i.e. Blazor

I’m leaving out the huge amount of complexity in the front-end here. It’s a minefield. So many options, so many ways to think you can save time by using open-source components and so many ways to find you need to develop something bespoke or try and customise the hell out of that open-source component only to bin it because it doesn’t work (been there more times than I’d like).

Regarding the WASM architecture - I’m starting out on building a new web-app atm for the galleries using Blazor (server-side mode).

1 Like
#5

Interesting reading, I’ve got some blind spots here I’ll get googling

#6

The mobile experience was the weak point.

As for the directory I’d keep it because people still ask questions “I’m in se of London where can I get an MOT”. A community driven directory would be great.

2 Likes
#7

The new LB Photos website is well into development now. Interested parties can see the source code here:

Admin categories and gallery creation is working with image upload to cloud storage and dynamic image rendering just added.

Off the cuff comments: Azure Cosmos DB is bloody expensive. Domain model caching to come at some point before deployment to a public server to help reduce database use and cost for read operations.

1 Like
#8

should have gone with Bezos! :smiley:

#9

Nah, they cost as much as each other service for service. What I could have done was used a SQL database instead and just lived with the overhead of schema changes (via migrations). The nice thing about a document database (which Cosmos is) is there’s no schema so development is a lot quicker.

Found some ways to reduce costs further with point reads, should be able to make it cost effective. Should :slight_smile:

1 Like
#10

Other thing to remember is that one if the main reasons for cosmos is geographical distribution, thats why it is so expensive. Its targeted at solutions that would be used accross the globe.

What aspect of the application are you using for the DB?

For sql, schema changes can be a pain but from the sounds of it are you using .Net? If so then entity framework takes a lot of the hassle away if you do a code fist deployment it deals with everything.

Then you can use Serverless Azure Sql its brilliant !!

1 Like
#11

Aye, Cosmos DB is amazing. We’re using it as a Document DB via the SQL API. The primary reason for selecting it was the benefit of not having to manage a schema which accelerates development whilst making constant changes to model structure.

Otherwise, yes we’d use Azure SQL and Entity Framework automatic code migrations. It’s a great mechanism and one I’ve used for years, but all the same, it is an overhead to development that would be nice to sidestep if possible.

We’ll see how far we get with query optimisations and caching to reduce the request charges. I’ve just eliminated some queries in favour of point reads which drops many read request charges from 2.7 or so down to 1, so a nice improvement. Caching not in yet but that’ll eliminate a huge amount of reads and allow us to reduce charges where we absolutely have to query by just returning object IDs rather than whole objects (which helps as you pay for how much data you return over the wire) that we then use to query objects from the cache.

It’s my first time properly using a Document database, though not my first time with partitioning thankfully.

#12

Should we rename this to “view our source code?”

#13

Done.

1 Like